On 2021-Apr-07, Andres Freund wrote:
> I'm also confused by the use of ConditionVariableTimedSleep(timeout =
> 10). Why do we need a timed sleep here in the first place? And why with
> such a short sleep?
I was scared of the possibility that a process would not set the CV for
whatever reason, causing checkpointing to become stuck. Maybe that's
misguided thinking if CVs are reliable enough.
> I also noticed that the code is careful to use CHECK_FOR_INTERRUPTS(); -
> but is aware it's running in checkpointer. I don't think CFI does much
> there? If we are worried about needing to check for interrupts, more
> work is needed.
Hmm .. yeah, doing CFI seems pretty useless. I think that should just
be removed. If checkpointer gets USR2 (request for shutdown) it's not
going to affect the behavior of CFI anyway.
I attach a couple of changes to your 0001. It's all cosmetic; what
looks not so cosmetic is the change of "continue" to "break" in helper
routine; if !s->in_use, we'd loop infinitely. The other routine
already checks that before calling the helper; since you hold
ReplicationSlotControlLock at that point, it should not be possible to
drop it in between. Anyway, it's a trivial change to make, so it should
be correct.
I also added a "continue" at the bottom of one block; currently that
doesn't change any behavior, but if we add code at the other block, it
might not be what's intended.
> After this I don't see a reason to have SAB_Inquire - as far as I can
> tell it's practically impossible to use without race conditions? Except
> for raising an error - which is "builtin"...
Hmm, interesting ... If not needed, yeah let's get rid of that.
Are you getting this set pushed, or would you like me to handle it?
(There seems to be some minor conflict in 13)
--
Álvaro Herrera Valdivia, Chile
"Pido que me den el Nobel por razones humanitarias" (Nicanor Parra)