Re: Problem with PITR recovery

On Wed, 2005-04-20 at 15:51 -0400, Tom Lane wrote:
> Simon Riggs <simon(at)2ndquadrant(dot)com> writes:
> > AFAICS this is the only case of unconditionally acquiring all 3 locks.
>
> You just lost me ... I think the above is certainly a bad idea from a
> concurrency standpoint, and very possibly a deadlock risk.

'twas my fear too.

> In any case you are thinking about it the wrong way. It is not
> LogwrtResult you want to advance, it is the Insert variables that define
> what the current WAL buffer page is.

Yes OK, so that way I don't need the 3 locks. Good.

> ISTM the correct approach involves having a special case in XLogInsert:
> just after inserting an end-of-file record, forcibly advance to the next
> buffer, and set it up to be the first page for the next segment rather
> than the next segment in sequence. (This is likely best handled as an
> extra call to AdvanceXLInsertBuffer that invokes some special-case code
> in AdvanceXLInsertBuffer.) You normally only need the WALInsertLock to
> do this. After that's complete you can release the insert lock, and
> then other operations can proceed while you do an XLogFlush to force out
> the remaining dirty WAL buffers for the old segment. Then you're done.

Good. Thats was roughly what I'm attempting now, just advancing the
wrong pointer and struggling/worried by the 3 lock problem.

> (I think I'd put the XLogFlush in the pg_stop_backup code, not in
> XLogInsert proper.)

That seems like the way its done elsewhere.

Best Regards, Simon Riggs