| From: | Gregory Stark <stark(at)enterprisedb(dot)com> |
|---|---|
| To: | "Simon Riggs" <simon(at)2ndquadrant(dot)com> |
| Cc: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, "Jeff Trout" <threshar(at)threshar(dot)is-a-geek(dot)com>, <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: [GENERAL] Slow PITR restore |
| Date: | 2007-12-13 11:03:13 |
| Message-ID: | 873au66emm.fsf@oxford.xeocode.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general pgsql-hackers |
"Simon Riggs" <simon(at)2ndquadrant(dot)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!
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Richard Broersma Jr | 2007-12-13 11:06:12 | Re: For the SQL gurus out there |
| Previous Message | Simon Riggs | 2007-12-13 10:21:48 | Re: [GENERAL] Slow PITR restore |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alvaro Herrera | 2007-12-13 11:45:18 | Re: [HACKERS] "distributed checkpoint" |
| Previous Message | Simon Riggs | 2007-12-13 10:46:04 | [Fwd: [PATCHES] archiver ps display] |