From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Michael Paquier > > By the way, doesn't this wait event belong to IPC wait event type, because > the process is waiting for other conflicting processes to terminate the > conflict conditions? Did you choose Timeout type because > max_standby_{archive | streaming}_delay relates to this wait? I'm not > confident which is appropriate, but I'm afraid users can associate this > wait with a timeout. > > Actually I think that this event belongs to the timeout category, because > we wait until the timeout has finished, the latch being here to be sure > that the process is more responsive in case of a postmaster death.
OK. I confirmed the doc is fixed. > > (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. > > (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. Regards Takayuki Tsunakawa -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
