Thread: _bt_delitems: change before WAL?

Hi,

It's often said that the golden rule of WAL is that we must log the
changes before actually doing the changes.  However it seems to me that
in _bt_delitems we're modifying the page (calling PageIndexMultiDelete)
before actually logging what's going to happen.  Why is this OK?

I see that we're holding the "super exclusive" lock on the page, but
does this promise that the bgwriter won't write the page early?  Another
thing that I notice is that the buffer is not marked dirty until much
later in btbulkdelete.  But what if the buffer was dirty beforehand?

-- 
Alvaro Herrera                                http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

Alvaro Herrera <alvherre@commandprompt.com> writes:
> It's often said that the golden rule of WAL is that we must log the
> changes before actually doing the changes.

No, the golden rule is that the log entry must hit disk before the
data-page changes do.  This does not speak to the order in which you
make the changes in memory.

> However it seems to me that
> in _bt_delitems we're modifying the page (calling PageIndexMultiDelete)
> before actually logging what's going to happen.  Why is this OK?

Because we have write lock on the buffer, which will prevent anyone else
from writing it out (or even looking at it).  This is exactly like all the
other WAL-logging actions; see the WAL coding rules in access/transam/README.
        regards, tom lane