database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-07-30 11:03:19 +03:00
Code Activity

In HS, Startup process sets SIGALRM when waiting for buffer pin. If

Browse Source 
woken by alarm we send SIGUSR1 to all backends requesting that they
check to see if they are blocking Startup process. If so, they throw
ERROR/FATAL as for other conflict resolutions. Deadlock stop gap
removed. max_standby_delay = -1 option removed to prevent deadlock.
This commit is contained in:
Simon Riggs
2010-01-23 16:37:12 +00:00
parent 4fa69e566c
commit 959ac58c04
16 changed files with 367 additions and 87 deletions
Download Patch File Download Diff File Expand all files Collapse all files

16
doc/src/sgml/backup.sgml
View File

@ -1,4 +1,4 @@
<!-- $PostgreSQL: pgsql/doc/src/sgml/backup.sgml,v 2.136 2010/01/15 09:18:56 heikki Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/backup.sgml,v 2.137 2010/01/23 16:37:12 sriggs Exp $ -->
<chapter id="backup">
<title>Backup and Restore</title>
@ -2399,7 +2399,7 @@ primary_conninfo = 'host=192.168.1.50 port=5432 user=foo password=foopass'
</listitem>
<listitem>
<para>
Waiting to acquire buffer cleanup locks (for which there is no time out)
Waiting to acquire buffer cleanup locks
</para>
</listitem>
<listitem>
@ -2536,11 +2536,7 @@ primary_conninfo = 'host=192.168.1.50 port=5432 user=foo password=foopass'
Three-way deadlocks are possible between AccessExclusiveLocks arriving from
the primary, cleanup WAL records that require buffer cleanup locks and
user requests that are waiting behind replayed AccessExclusiveLocks. Deadlocks
are currently resolved by the cancellation of user processes that would
need to wait on a lock. This is heavy-handed and generates more query
cancellations than we need to, though does remove the possibility of deadlock.
This behaviour is expected to improve substantially for the main release
version of 8.5.
are resolved by time-out when we exceed <varname>max_standby_delay</>.
</para>
<para>
@ -2630,11 +2626,7 @@ LOG: database system is ready to accept read only connections
<varname>max_standby_delay</> or even set it to zero, though that is a
very aggressive setting. If the standby server is tasked as an additional
server for decision support queries then it may be acceptable to set this
to a value of many hours (in seconds). It is also possible to set
<varname>max_standby_delay</> to -1 which means wait forever for queries
to complete, if there are conflicts; this will be useful when performing
an archive recovery from a backup.
</para>
to a value of many hours (in seconds).
<para>
Transaction status "hint bits" written on primary are not WAL-logged,

15
doc/src/sgml/config.sgml
View File

@ -1,4 +1,4 @@
<!-- $PostgreSQL: pgsql/doc/src/sgml/config.sgml,v 1.244 2010/01/15 09:18:58 heikki Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/config.sgml,v 1.245 2010/01/23 16:37:12 sriggs Exp $ -->
<chapter Id="runtime-config">
<title>Server Configuration</title>
@ -1825,14 +1825,15 @@ archive_command = 'copy "%p" "C:\\server\\archivedir\\%f"' # Windows
<listitem>
<para>
When server acts as a standby, this parameter specifies a wait policy
for queries that conflict with incoming data changes. Valid settings
are -1, meaning wait forever, or a wait time of 0 or more seconds.
If a conflict should occur the server will delay up to this
amount before it begins trying to resolve things less amicably, as
for queries that conflict with data changes being replayed by recovery.
If a conflict should occur the server will delay up to this number
of seconds before it begins trying to resolve things less amicably, as
described in <xref linkend="hot-standby-conflict">. Typically,
this parameter makes sense only during replication, so when
performing an archive recovery to recover from data loss a
parameter setting of 0 is recommended. The default is 30 seconds.
performing an archive recovery to recover from data loss a very high
parameter setting is recommended. The default is 30 seconds.
There is no wait-forever setting because of the potential for deadlock
which that setting would introduce.
This parameter can only be set in the <filename>postgresql.conf</>
file or on the server command line.
</para>