Re: AW: AW: AW: AW: AW: WAL-based allocation of XIDs is ins ecur e - Mailing list pgsql-hackers

From Tom Lane
Subject Re: AW: AW: AW: AW: AW: WAL-based allocation of XIDs is ins ecur e
Date
Msg-id 9547.983980824@sss.pgh.pa.us
Whole thread Raw
In response to AW: AW: AW: AW: AW: WAL-based allocation of XIDs is ins ecur e  (Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at>)
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: Re: Uh, this is *not* a 64-bit CRC ...
Next
From: Tom Lane
Date:
Subject: Re: AW: Proposed WAL changes