Re: Why does VACUUM FULL bother locking pages?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Why does VACUUM FULL bother locking pages?
Date: 2005-09-22 17:15:04
Message-ID: 200.1127409304@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> writes:
> Looking again, PageRepairFragmentation is called on a copy of the page,
> not on the page itself, so this is not a problem. The page is only
> modified to exchange old Xids for FrozenTransactionId, or to set some
> hint bits, so this really shouldn't be too much of a problem. I still
> think it would be better to lock the page beforehand.

Actually, the case that's a bit worrisome is the PageIsNew path: it'd be
possible for a partially-valid page header to be written out. This
wouldn't result in data loss, exactly, since there's nothing on the page
... but we might have a problem using the page later.

The FrozenTransactionId update case is already presumed to be atomic by
vacuumlazy.c, so I don't feel too bad about it, but it surely needs a
comment at least.

On the whole it seems like we might as well just take the exclusive
buffer lock and not try to be cute.

AFAICT the other routines in vacuum.c all do proper locking when they
are modifying pages, so it's just this one place that is taking a short
cut.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Josh Berkus 2005-09-22 18:01:41 Re: Hierarchical Queries--Stalled No Longer...
Previous Message Thomas Hallgren 2005-09-22 16:45:45 Re: What has happened to pgxs?