On Thu, Mar 30, 2017 at 1:52 PM, Tsunakawa, Takayuki <tsunakawa.ta...@jp.fujitsu.com> wrote: > From: pgsql-hackers-ow...@postgresql.org >> > (2) standby.c >> > Do we need to specify WL_LATCH_SET? Who can set the latch? Do the >> backends who ended the conflict set the latch? >> >> This makes the process able to react on SIGHUP. That's useful for >> responsiveness. > > Oh, I see. But how does the startup process respond quickly? It seems that > you need to call HandleStartupProcInterrupts() instead of > CHECK_FOR_INTERRUPTS(). But I'm not sure whether > HandleStartupProcInterrupts() can be called here.
Bah. Of course you are right. We don't care about SetLatch() here as signals are processed with a different code path than normal backends. >> > (3) standby.c >> > + if (rc & WL_LATCH_SET) >> > + ResetLatch(MyLatch); >> > + >> > + /* emergency bailout if postmaster has died */ >> > + if (rc & WL_POSTMASTER_DEATH) >> > + proc_exit(1); >> > >> > I thought the child processes have to terminate as soon as postmaster >> vanishes. So, it would be better for the order of the two if statements >> above to be reversed. proc_exit() could be exit(), as some children do >> in postmaster/*.c. >> >> OK, reversed this order. > > I think exit() instead of proc_exit() better represents what the code wants > to do -- terminate the process ASAP without cleaning up. Many other > background children do so. Hm... OK. -- Michael
standby-delay-latch-v5.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
