Re: Problem with PITR recovery - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Problem with PITR recovery
Date
Msg-id 4096.1114026683@sss.pgh.pa.us
Whole thread Raw
In response to Re: Problem with PITR recovery  (Simon Riggs <simon@2ndquadrant.com>)
Responses Re: Problem with PITR recovery  (Simon Riggs <simon@2ndquadrant.com>)
List pgsql-hackers
Simon Riggs <simon@2ndquadrant.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.

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.

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.
(I think I'd put the XLogFlush in the pg_stop_backup code, not in
XLogInsert proper.)
        regards, tom lane


pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: Postgres: pg_hba.conf, md5, pg_shadow, encrypted passwords
Next
From: Tom Lane
Date:
Subject: Re: Problem with PITR recovery