Re: [COMMITTERS] pgsql: Introduce WAL records to log reuse of btree pages, allowing

Поиск
Список
Период
Сортировка
От Simon Riggs
Тема Re: [COMMITTERS] pgsql: Introduce WAL records to log reuse of btree pages, allowing
Дата
Msg-id 1266513417.7341.9863.camel@ebony
обсуждение исходный текст
Ответ на Re: [COMMITTERS] pgsql: Introduce WAL records to log reuse of btree pages, allowing  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Ответы Re: Re: [COMMITTERS] pgsql: Introduce WAL records to log reuse of btree pages, allowing  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Thu, 2010-02-18 at 14:23 +0200, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > Introduce WAL records to log reuse of btree pages, allowing conflict
> > resolution during Hot Standby. Page reuse interlock requested by Tom.
> > Analysis and patch by me.
> 
> There's still a theoretical possibility for this to happen:
> 
> 1. A page is marked as deleted by VACUUM, setting xact field in the opaque
> 2. Master crashes. WAL replay replays the XLOG_BTREE_DELETE_PAGE record.
> It resets the xact field to FrozenTransactionId
> 3. The page is recycled. This writes a XLOG_BTREE_REUSE_PAGE record with
> FrozenTransactionId as latestRemovedXid
> 
> When the standby replays that, it will call
> ResolveRecoveryConflictWithSnapshot with FrozenTransactionid, not the
> original xid that was used in the master when the page was deleted.

> A straightforward way to fix that is to WAL-log the real xid in the
> XLOG_BTREE_DELETE_PAGE records, instead of resetting it to
> FrozenTransactionId.

An even simpler way would be to reset the value to latestCompletedXid
during btree_xlog_delete_page(). That touches less code. I doubt it will
make much difference to conflict recovery, since if pages are being
deleted then btree delete records are likely to be frequent and will
have already killed long running queries.

-- Simon Riggs           www.2ndQuadrant.com



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Dimitri Fontaine
Дата:
Сообщение: Re: Avoiding bad prepared-statement plans.
Следующее
От: "David E. Wheeler"
Дата:
Сообщение: Re: PostgreSQL::PLPerl::Call - Simple interface for calling SQL functions from PostgreSQL PL/Perl