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 */

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 

* 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?

Takayuki Tsunakawa

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to