On Thu, Dec 12, 2013 at 3:42 PM, Fabrízio de Royes Mello < fabriziome...@gmail.com> wrote: > > On Thu, Dec 12, 2013 at 3:39 PM, Simon Riggs <si...@2ndquadrant.com> wrote: > > > > On 12 December 2013 15:19, Simon Riggs <si...@2ndquadrant.com> wrote: > > > > > Don't panic guys! I meant UTC offset only. And yes, it may not be > > > needed, will check. > > > > Checked, all non-UTC TZ offsets work without further effort here. > > > > Thanks! >
Reviewing the committed patch I noted that the "CheckForStandbyTrigger()" after the delay was removed. If we promote the standby during the delay and don't check the trigger immediately after the delay, then we will replay undesired WALs records. The attached patch add this check. Regards, -- Fabrízio de Royes Mello Consultoria/Coaching PostgreSQL >> Timbira: http://www.timbira.com.br >> Blog sobre TI: http://fabriziomello.blogspot.com >> Perfil Linkedin: http://br.linkedin.com/in/fabriziomello >> Twitter: http://twitter.com/fabriziomello
diff --git a/src/backend/access/transam/xlog.c b/src/backend/access/transam/xlog.c index a76aef3..fbc2d2f 100644 --- a/src/backend/access/transam/xlog.c +++ b/src/backend/access/transam/xlog.c @@ -6835,6 +6835,14 @@ StartupXLOG(void) recoveryApplyDelay(); /* + * Check for standby trigger to prevent the + * replay of undesired WAL records if the + * slave was promoted during the delay. + */ + if (CheckForStandbyTrigger()) + break; + + /* * We test for paused recovery again here. If * user sets delayed apply, it may be because * they expect to pause recovery in case of
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
