From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> |
Cc: | dilipbalaut(at)gmail(dot)com, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Problem while setting the fpw with SIGHUP |
Date: | 2018-03-27 13:02:26 |
Message-ID: | 20180327130226.GA1105@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Mar 27, 2018 at 09:01:20PM +0900, Kyotaro HORIGUCHI wrote:
> The current UpdateFullPageWrites is safe on standby and promotion
> so what we should consider is only the non-standby case. I think
> what we should do is just calling RecoveryInProgress() at the
> beginning of CheckPointerMain, which is just the same thing with
> InitPostgres, but before setting up signal handler to avoid
> processing SIGHUP before being ready to insert xlog.
Your proposal does not fix the issue for a checkpointer process started
on a standby. After a promotion, if SIGHUP is issued with a change in
full_page_writes, then the initialization of InitXLogInsert() would
happen again in the critical section of UpdateFullPageWrites(). The
window is rather small for normal promotions as the startup process
requests a checkpoint which would do the initialization, and much larger
for fallback_promote where the startup process is in charge of doing the
end-of-recovery checkpoint.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Arthur Zakirov | 2018-03-27 13:04:00 | Re: Ensure that maxlen is an integer value in dict_int configuration |
Previous Message | Etsuro Fujita | 2018-03-27 13:00:36 | Oddity in COPY FROM handling of check constraints on partition tables |