Re: [GENERAL] Slow PITR restore

Поиск
Список
Период
Сортировка
От Gregory Stark
Тема Re: [GENERAL] Slow PITR restore
Дата
Msg-id 873au66emm.fsf@oxford.xeocode.com
обсуждение исходный текст
Ответ на Re: [GENERAL] Slow PITR restore  (Simon Riggs <simon@2ndquadrant.com>)
Ответы Re: [GENERAL] Slow PITR restore  (Heikki Linnakangas <heikki@enterprisedb.com>)
Список 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 по дате отправления:

Предыдущее
От: Simon Riggs
Дата:
Сообщение: [Fwd: [PATCHES] archiver ps display]
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: [DOCS] "distributed checkpoint"