Re: AW: WAL-based allocation of XIDs is insecure

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: AW: WAL-based allocation of XIDs is insecure
Дата
Msg-id 5493.983892536@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: AW: WAL-based allocation of XIDs is insecure  (Hiroshi Inoue <Inoue@tpf.co.jp>)
Список pgsql-hackers
Hiroshi Inoue <Inoue@tpf.co.jp> writes:
> Yes there must be XLogFlush() before writing buffers.
> BTW how do we get the next XID if WAL files are corrupted ?

My not-yet-committed changes include storing the latest CheckPoint
record in pg_control (as well as in the WAL files).  Recovery from
XLOG disaster will consist of generating a new XLOG that's empty
except for a CheckPoint record based on the one cached in pg_control.
In particular we can extract the nextOid and nextXid fields.

It might be that writing NEXTXID or NEXTOID log records should update
pg_control too with new nextXid/nextOid values --- what do you think?
Otherwise there's a possibility that the stored checkpoint is too far
back to cover all the values used since then.  OTOH, we are not going
to be able to guarantee absolute consistency in this disaster recovery
scenario anyway; duplicate XIDs may be the least of one's worries.

Of course, if you lose both XLOG and pg_control, you're still in big
trouble.  So it seems we should minimize the number of writes to
pg_control, which is an argument not to update it more than we must.
        regards, tom lane


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

Предыдущее
От: Christof Petig
Дата:
Сообщение: Query Planning time increased 3 times on 7.1 compared to 7.0.3
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Proposed WAL changes