From: Michael Paquier [mailto:[email protected]]
> Oops, sorry for that, I quite mess up with this patch. The WaitLatch() call
> should still have WL_POSTMASTER_DEATH so as it can leave earlier, but yes
> I agree with your analysis that HandleStartupProcInterrupts() as this is
> part of the redo work.
Thank you, but did you remove WL_LATCH_SET from WaitLatch() intentionally? I
understood you added it for startup process to respond quickly to events other
than the postmaster death. Why don't we restore WL_LATCH_SET? I won't object
to not adding the flag if there's a reason.
I'll mark this as ready for committer when I see WL_LATCH_SET added (optional)
and you have reported that you did the following test cases:
* Startup process vanishes immediately after postmaster dies, while it is
waiting for a recovery conflict to be resolved.
* Startup process vanishes immediately after "pg_ctl stop -m fast", while it is
waiting for a recovery conflict to be resolved.
* Startup process resumes WAL application when max_standby_{archive |
streaming}_delay is changed from the default -1 to a short period, e.g. 10s,
and "pg_ctl reload" is performed, while it is waiting for a recovery conflict
to be resolved.
> > Did Simon's committed patch solve the problem as expected?
>
> Does not seem so, I'll let Simon comment on this matter...
Agreed. I guess his patch for earlier releases should work if
CHECK_FOR_INTERRUPTS() is replaced with HandleStartupProcInterrupts().
Regards
Takayuki Tsunakawa
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
