Re: [GENERAL] Slow PITR restore - Mailing list pgsql-hackers

From Gregory Stark
Subject Re: [GENERAL] Slow PITR restore
Date
Msg-id 873au66emm.fsf@oxford.xeocode.com
Whole thread Raw
In response to Re: [GENERAL] Slow PITR restore  (Simon Riggs <simon@2ndquadrant.com>)
Responses Re: [GENERAL] Slow PITR restore
List pgsql-hackers
"Simon Riggs" <simon@2ndquadrant.com> writes:

> We would have readbuffers in shared memory, like wal_buffers in reverse.
> Each worker would read the next WAL record and check there is no
> conflict with other concurrent WAL records. If not, it will apply the
> record immediately, otherwise wait for the conflicting worker to
> complete. 

Well I guess you would have to bring up the locking infrastructure and lock
any blocks in the record you're applying (sorted first to avoid deadlocks). As
I understand it we don't use locks during recovery now but I'm not sure if
that's just because we don't have to or if there are practical problems which
would have to be solved to do so.

--  Gregory Stark EnterpriseDB          http://www.enterprisedb.com Ask me about EnterpriseDB's Slony Replication
support!


pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: [Fwd: [PATCHES] archiver ps display]
Next
From: Alvaro Herrera
Date:
Subject: Re: [DOCS] "distributed checkpoint"