Re: AW: AW: AW: AW: AW: WAL-based allocation of XIDs is ins ecur e

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: AW: AW: AW: AW: AW: WAL-based allocation of XIDs is ins ecur e
Дата
Msg-id 9547.983980824@sss.pgh.pa.us
обсуждение исходный текст
Ответ на AW: AW: AW: AW: AW: WAL-based allocation of XIDs is ins ecur e  (Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at>)
Список pgsql-hackers
Zeugswetter Andreas SB  <ZeugswetterA@wien.spardat.at> writes:
> I really think that xlog entries should be done by a layer below the
> userland functions.

That seems somewhere between impractical and impossible: how will you
tie the functional xlog entries ("insert foo into index bar") to the
resulting page modifications, unless the entries are made from code
that knows all about which pages contain what index entries?  Don't
forget these things need to go into the xlog atomically.

> I would not like to risc WAL integrity by allowing
> userland to write a messed up log record.

Index access method code is just as critical a part of the system as
anything else.  The above makes no more sense than saying that you don't
want to trust heapam.c to generate correct WAL records.

> Actually I am not sure index changes need to be (or are currently)
> logged at all.  You can deduce all necessary info from the heap xlog
> record (plus maybe the original record from disk).

This assumes that pg_index, pg_am and friends are (a) not corrupt; (b)
in the same state that they were in when the portion of the XLOG being
replayed was made.  Neither of these assumptions is acceptable for WAL
recovery.

I do think there's something to your notion that XLOG should be logging
the pre-modification pages rather than post-modification, but that's
something we will have to come back to in 7.2 or later.  For 7.1's
purposes there is nothing wrong with the current scheme, and I have no
desire to postpone release another few months to change it.
        regards, tom lane


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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Re: Uh, this is *not* a 64-bit CRC ...
Следующее
От: Tom Lane
Дата:
Сообщение: Re: AW: Proposed WAL changes