Re: Stefan's bug (was: max_standby_delay considered harmful)
Simon Riggs <simon@2ndquadrant.com>
From: Simon Riggs <simon@2ndQuadrant.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Fujii Masao <masao.fujii@gmail.com>, Alvaro Herrera <alvherre@alvh.no-ip.org>, Stefan Kaltenbrunner <stefan@kaltenbrunner.cc>, Andres Freund <andres@anarazel.de>, Florian Pflug <fgp@phlo.org>, Dimitri Fontaine <dfontaine@hi-media.com>, Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers <pgsql-hackers@postgresql.org>, Bruce Momjian <bruce@momjian.us>, Greg Smith <greg@2ndquadrant.com>, Josh Berkus <josh@agliodbs.com>
Date: 2010-05-24T13:28:46Z
Lists: pgsql-hackers
On Mon, 2010-05-24 at 09:26 -0400, Robert Haas wrote: > On Mon, May 24, 2010 at 1:27 AM, Fujii Masao <masao.fujii@gmail.com> wrote: > > On Wed, May 19, 2010 at 2:47 PM, Fujii Masao <masao.fujii@gmail.com> wrote: > >>>> Oh, right. How about allowing the postmaster only in PM_STARTUP, > >>>> PM_RECOVERY, PM_HOT_STANDBY or PM_WAIT_READONLY state to invoke > >>>> walreceiver? We can keep walreceiver alive until all read only > >>>> backends have gone, and prevent unexpected startup of walreceiver. > >>> > >>> Yes, that seems like something we should be checking, if we aren't already. > >> > >> I'll do that. > > > > Here is the updated version. I added the above-mentioned check > > into the patch. > > This looks pretty reasonable to me, but I guess I feel like it would > be better to drive the CancelBackup() decision off of whether we've > ever reached PM_RUN rather than consulting XLogCtl. That is exactly what XLogCtl tells us and why it is suggested for use. > It just feels > cleaner to me to drive all of the postmaster decisions off of the same > signalling mechanism rather than having a separate one (that only > works because it's used very late in shutdown when we theoretically > don't need a lock) just for this one case. > > I could be all wet, though. > -- Simon Riggs www.2ndQuadrant.com