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
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 |