Horton
Menu

Re: Stefan's bug (was: max_standby_delay considered harmful)

Simon Riggs <simon@2ndquadrant.com>

View thread
From: Simon Riggs <simon@2ndQuadrant.com>
To: Fujii Masao <masao.fujii@gmail.com>
Cc: Robert Haas <robertmhaas@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-18T08:10:50Z
Lists: pgsql-hackers 
On Tue, 2010-05-18 at 16:05 +0900, Fujii Masao wrote:
> >>> >> ISTM that we can use XLogCtl->SharedRecoveryInProgress for that.
> >>> >> Is this OK?
> >>> >
> >>> > That can change state at any time. Would that work?
> >>>
> >>> Yes. XLogCtl->SharedRecoveryInProgress is set to TRUE only when
> >>> XLogCtl structure is initialized (i.e., XLOGShmemInit), and it's
> >>> set to FALSE only at the end of recovery.
> >>
> >> You should be using RecoveryInProgress()
> >
> > Isn't access to a bool variable atomic?
> 
> If it's not atomic, I'll add the following comment into CancelBackup():
> 
>     Don't bother with lock to access XLogCtl->SharedRecoveryInProgress,
>     because there should be no other processes running when this code
>     is reached.

Call it via a function. There is no need for postmaster to know the
innards of xlog.c, which could change in future. Modularity.

-- 
 Simon Riggs           www.2ndQuadrant.com