From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Zeugswetter Andreas SB <ZeugswetterA(at)wien(dot)spardat(dot)at> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: AW: AW: AW: WAL-based allocation of XIDs is insecure |
Date: | 2001-03-06 17:31:30 |
Message-ID: | 6360.983899890@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
I wrote:
> The decision whether to log the whole buffer has to be atomic with the
> actual entry of the xlog record. Unless we want to hold the xlog insert
> lock for the entire time that we're (eg) splitting a btree page, that
> means we log the buffer after the modification work is done, not before.
On third thought --- we could still log the original page contents and
the modification log record atomically, if what were logged in the xlog
record were (essentially) the parameters to the operation being logged,
not its results. That is, make the log entry before you start doing the
mod work, not after. This might also simplify redo, since redo would be
no different from the normal case. I'm not sure why Vadim didn't choose
to do it that way; maybe there's some other fine point I'm missing.
In any case, it'd be a big code change and not something I'd want to
undertake at this point in the release cycle ... maybe we can revisit
this issue for 7.2.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Zeugswetter Andreas SB | 2001-03-06 17:46:30 | AW: AW: AW: AW: WAL-based allocation of XIDs is insecur e |
Previous Message | Peter Eisentraut | 2001-03-06 17:18:06 | Re: mailing list messages |