Hi Michael, Simon, From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Michael Paquier > > 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.
So, I understood you agreed that CHECK_FOR_INTERRUPTS() here does nothing. But your patch still calls it: + /* An interrupt may have occurred while waiting */ + CHECK_FOR_INTERRUPTS(); I got confused because the problem is not defined in this thread. What problem does this patch address? These ones? * The startup process terminates as soon as postmaster dies. * pg_stat_activity does not show the wait event of startup process waiting for a recovery conflict resolution. My guess about why you decided to not call HandleStartupProcInterrupts() here is: * Respond to postmaster death here. * No need to reload config file here because there's no parameter to affect this conflict wait. But max_standby_{archive | streaming}_delay seems to affect the wait period. * No need to handle SIGTERM and exit here, because the startup process doesn't wait for a conflict resolution here when he can terminate. I think you can call HandleStartupProcInterrupts() here, instead of checking postmaster death. Did you perform tests? Did Simon's committed patch solve the problem as expected? 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