Re: WAL-based allocation of XIDs is insecure - Mailing list pgsql-hackers

From Vadim Mikheev
Subject Re: WAL-based allocation of XIDs is insecure
Date
Msg-id 053c01c0a6f1$8ee55fe0$4879583f@sectorbase.com
Whole thread Raw
In response to WAL-based allocation of XIDs is insecure  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
> Consider the following scenario:
> 
> 1. A new transaction inserts a tuple.  The tuple is entered into its
> heap file with the new transaction's XID, and an associated WAL log
> entry is made.  Neither one of these are on disk yet --- the heap tuple
> is in a shmem disk buffer, and the WAL entry is in the shmem WAL buffer.
> 
> 2. Now do a lot of read-only operations, in the same or another backend.
> The WAL log stays where it is, but eventually the shmem disk buffer will
> get flushed to disk so that the buffer can be re-used for some other
> disk page.
> 
> 3. Assume we now crash.  Now, we have a heap tuple on disk with an XID
> that does not correspond to any XID visible in the on-disk WAL log.

Impossible (with fsync ON -:)).

Seems my description of core WAL rule was bad, I'm sorry -:(
WAL = Write-*Ahead*-Log = Write data pages *only after* log records
reflecting data pages modifications are *flushed* on disk =
If a modification was not logged then it's neither in data pages.

No matter when bufmgr writes data buffer (at commit time or to re-use
it) bufmgr first ensures that buffer' modifications are logged.

Vadim




pgsql-hackers by date:

Previous
From: Zeugswetter Andreas SB
Date:
Subject: AW: How to shoot yourself in the foot: kill -9 postmast er
Next
From: Andrew McMillan
Date:
Subject: Re: How to shoot yourself in the foot: kill -9 postmaster