Simon Riggs wrote:
> On Fri, 2009-01-23 at 17:51 +0200, Heikki Linnakangas wrote:
>> ISTM that if ReadBuffer read the value directly from the PGPROC entry,
>> there would be no need for the signaling (in the ERROR mode).
>
> That is possible and I considered it. If we did it that way we would
> need to read the PGPROC each time we read a buffer. AFAICS we would need
> to use a spinlock to do that since reading an XLogRecPtr would not be
> atomic.
Hmm, I think you could make it lock-free by ordering the instructions
carefully. Not sure it's worth the code complexity, though.
>> Correct me if I'm wrong, but I thought the idea of this new conflict
>> resolution was that the startup process doesn't need to wait for the
>> target backend to die. Instead, the target backend knows to commit
>> suicide if it stumbles into a buffer that's been modified in a
>> conflicting way. Looking at ResolveRecoveryConflictWithVirtualXIDs, it
>> looks like we still wait.
>
> err, no, that's just an oversight, not intentional.
Ok, then I think we have a little race condition. The startup process
doesn't get any reply indicating that the target backend has processed
the SIGINT and set the cached conflict LSN. The target backend might
move ahead using the old LSN for a little while, even though the startup
process has already gone ahead and replayed a vacuum record.
Another tiny issue is that it looks like a new conflict LSN always
overwrites the old one. But you should always use the oldest conflicted
LSN in the checks, not the newest.
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
