Re: XLOG_NO_TRAN and XLogRecord.xl_xid

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Heikki Linnakangas <heikki(at)enterprisedb(dot)com>
Cc: "Florian G(dot) Pflug" <fgp(at)phlo(dot)org>, Postgresql-General <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: XLOG_NO_TRAN and XLogRecord.xl_xid
Date: 2007-02-22 16:11:35
Message-ID: 5712.1172160695@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Heikki Linnakangas <heikki(at)enterprisedb(dot)com> writes:
> Florian G. Pflug wrote:
>> * Note: xlog record is marked as outside transaction control, since we
>> * want it to be redone whether the invoking transaction commits or not.

> That comment is a bit misleading, I agree. We don't skip xlog entries,
> they're always replayed.

Yeah, this distinction is another bit of effectively-dead code left over
from Vadim's original plan of using WAL for UNDO. I haven't worried
about ripping it out because it doesn't cost much and it seems that
distinguishing transactional from nontransactional changes might be
useful for log analysis if nothing else.

> Yep, that's right. The reconstructed page is not always byte-to-byte
> identical to the original.

We don't worry about recovering cmin/cmax since only the originating
transaction would have cared. I think physical location of tuples on
a page isn't reliably reproduced either.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2007-02-22 16:18:19 Re: tsearch in core patch, for inclusion
Previous Message Heikki Linnakangas 2007-02-22 16:05:07 Re: XLOG_NO_TRAN and XLogRecord.xl_xid