From: | "Vadim Mikheev" <vmikheev(at)sectorbase(dot)com> |
---|---|
To: | "PostgreSQL Development" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: WAL-based allocation of XIDs is insecure |
Date: | 2001-03-07 10:29:49 |
Message-ID: | 053c01c0a6f1$8ee55fe0$4879583f@sectorbase.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew McMillan | 2001-03-07 10:39:28 | Re: How to shoot yourself in the foot: kill -9 postmaster |
Previous Message | Zeugswetter Andreas SB | 2001-03-07 10:25:20 | AW: How to shoot yourself in the foot: kill -9 postmast er |