Peter Geoghegan <peter@2ndquadrant.com> writes:
> On 9 May 2012 00:21, Peter Geoghegan <peter@2ndquadrant.com> wrote:
>> Yes, there is some checking of flags before the potential ResetLatch()
>> call, which may be acted on. The code there is almost identical to
>> that of the extant bgwriter code. I was under the impression that this
>> did not amount to a race, though it's rather late now, and I'm feeling
>> under the weather, so I have not taken steps to verify that I have it
>> right. Arguably, you'd want somebody's SetLatch call to be ignored if
> Sent too early. That should be: Arguably, you'd want somebody's
> SetLatch call to be ignored under the circumstances that that could
> happen in both the bgwriter, and the WALWriter within my recent patch.
I don't believe that for a moment, and even if it accidentally manages
to not fail in today's code, it's *way* too fragile for my taste.
I believe the bgwriter code needs to be fixed similarly to the way
I changed the walwriter patch, namely that there needs to be a separate
flag (not the latch's isSet state) advertising whether the bgwriter is
currently in hibernation mode. Now, unlike the walwriter, there isn't
any convenient place to keep such a flag where it can be inspected
inside an already-existing spinlock or LWLock guard. However, unlike
the walwriter there is not a correctness requirement for the bgwriter
to wake up promptly. So I think we could just put a bool
"bgwriter_sleeping" in ProcGlobal and accept the possibility of other
processes sometimes seeing stale values. Thoughts?
regards, tom lane
