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

Поиск
Список
Период
Сортировка
От Heikki Linnakangas
Тема Re: [COMMITTERS] pgsql: Introduce WAL records to log reuse of btree pages, allowing
Дата
Msg-id 4B7D3135.3090204@enterprisedb.com
обсуждение исходный текст
Ответы Re: [COMMITTERS] pgsql: Introduce WAL records to log reuse of btree pages, allowing  (Simon Riggs <simon@2ndQuadrant.com>)
Re: [COMMITTERS] pgsql: Introduce WAL records to log reuse of btree pages, allowing  (Simon Riggs <simon@2ndQuadrant.com>)
Список pgsql-hackers
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.

--  Heikki Linnakangas EnterpriseDB   http://www.enterprisedb.com


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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: A thought: should we run pgindent now?
Следующее
От: Heikki Linnakangas
Дата:
Сообщение: Re: Streaming replication on win32, still broken