Обсуждение: pgsql: In HS, Startup process sets SIGALRM when waiting for buffer pin.
pgsql: In HS, Startup process sets SIGALRM when waiting for buffer pin.
От
sriggs@postgresql.org (Simon Riggs)
Дата:
Log Message:
-----------
In HS, Startup process sets SIGALRM when waiting for buffer pin. If
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.
Modified Files:
--------------
pgsql/doc/src/sgml:
backup.sgml (r2.136 -> r2.137)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/doc/src/sgml/backup.sgml?r1=2.136&r2=2.137)
config.sgml (r1.244 -> r1.245)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/doc/src/sgml/config.sgml?r1=1.244&r2=1.245)
pgsql/src/backend/access/transam:
xlog.c (r1.359 -> r1.360)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/access/transam/xlog.c?r1=1.359&r2=1.360)
pgsql/src/backend/storage/buffer:
bufmgr.c (r1.254 -> r1.255)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/storage/buffer/bufmgr.c?r1=1.254&r2=1.255)
pgsql/src/backend/storage/ipc:
procarray.c (r1.58 -> r1.59)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/storage/ipc/procarray.c?r1=1.58&r2=1.59)
procsignal.c (r1.3 -> r1.4)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/storage/ipc/procsignal.c?r1=1.3&r2=1.4)
standby.c (r1.6 -> r1.7)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/storage/ipc/standby.c?r1=1.6&r2=1.7)
pgsql/src/backend/storage/lmgr:
lock.c (r1.190 -> r1.191)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/storage/lmgr/lock.c?r1=1.190&r2=1.191)
proc.c (r1.213 -> r1.214)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/storage/lmgr/proc.c?r1=1.213&r2=1.214)
pgsql/src/backend/tcop:
postgres.c (r1.585 -> r1.586)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/tcop/postgres.c?r1=1.585&r2=1.586)
pgsql/src/backend/utils/misc:
guc.c (r1.533 -> r1.534)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/utils/misc/guc.c?r1=1.533&r2=1.534)
pgsql/src/include/storage:
bufmgr.h (r1.123 -> r1.124)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/include/storage/bufmgr.h?r1=1.123&r2=1.124)
proc.h (r1.118 -> r1.119)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/include/storage/proc.h?r1=1.118&r2=1.119)
procarray.h (r1.30 -> r1.31)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/include/storage/procarray.h?r1=1.30&r2=1.31)
procsignal.h (r1.3 -> r1.4)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/include/storage/procsignal.h?r1=1.3&r2=1.4)
standby.h (r1.4 -> r1.5)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/include/storage/standby.h?r1=1.4&r2=1.5)
On Sat, 2010-01-23 at 16:37 +0000, Simon Riggs wrote: > Log Message: > ----------- > In HS, Startup process sets SIGALRM when waiting for buffer pin. If > 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. Patch by me, review by Andres Freund and Hiroyuki Yamada -- Simon Riggs www.2ndQuadrant.com
On Sat, Jan 23, 2010 at 4:37 PM, Simon Riggs <sriggs@postgresql.org> wrote: > max_standby_delay = -1 option removed to prevent deadlock. This seems unacceptable to me. It means it's impossible to configure a reporting slave so it doesn't spuriously signal errors if your reports run too long. Recall that I am still of the opinion that the only reasonable default value for this parameter is actually -1. I don't think we should signal errors for correctly working systems unless the user requests them in some way. Was there any discussion about this change? I don't recall seeing it proposed on hackers. -- greg
On Sat, 2010-01-23 at 17:33 +0000, Greg Stark wrote: > Was there any discussion about this change? I don't recall seeing it > proposed on hackers. Unfortunately, you missed it. I posted the proposed patch, including the text of the commit message that I was planning to use on Tuesday, requesting reviews or commit by end of week. -- Simon Riggs www.2ndQuadrant.com