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: WAL-based allocation of XIDs is insecure |
Date: | 2001-03-06 15:20:35 |
Message-ID: | 5423.983892035@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Zeugswetter Andreas SB <ZeugswetterA(at)wien(dot)spardat(dot)at> writes:
>> 5. We will now run a new transaction with the same XID that was in use
>> before the crash. If that transaction commits, then we have a tuple on
>> disk that will be considered valid --- and should not be.
> I do not think this is true. Before any modification to a page the
> original page will be written to the log (aka physical log).
Hmm. Actually, what is written to the log is the *modified* page not
its original contents. However, on studying the buffer manager I see
that it tries to fsync the log entry describing the last mod to a data
page before it writes out the page itself. So perhaps that can be
relied on to ensure all XIDs known in the heap are known in the log.
However, I'd just as soon have the NEXTXID log records too to be doubly
sure. I do now agree that we needn't fsync the NEXTXID records,
however.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2001-03-06 15:28:56 | Re: AW: WAL-based allocation of XIDs is insecure |
Previous Message | kovacsz | 2001-03-06 15:07:36 | pg_dump writes SEQUENCEs twice with -a |