Re: Full page images in WAL & Cache Invalidation

From: "Florian G(dot) Pflug" <fgp(at)phlo(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Full page images in WAL & Cache Invalidation
Date: 2007-07-23 16:30:07
Message-ID: 46A4D78F.5080701@phlo.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane wrote:
> "Florian G. Pflug" <fgp(at)phlo(dot)org> writes:
>> I came up with the following plan for both inval events and locks
>> .) Store two flags in the commit record of a transaction, for
>> "transaction generated inval events" and "transaction held an
>> access exlusive lock".
>> .) Upon replay, block until no transactions are running (for
>> "transaction held an exclusive lock") before replaying the
>> record, or flush the caches after replaying it (for
>> "transaction generated inval events").
>
> This does not work; the lock has to be taken earlier than that.
> (See for instance VACUUM's truncate calls.) Not to mention that
> you have converted "exclusive lock on one table" to "exclusive lock
> on every table", which is even worse than the idea of converting
> per-table cache flushes to system-wide ones.

I'll check what VACUUM is doing.. I primarily had CLUSTER and TRUNCATE
in mind.

That "exclusive lock on one table becomes exclusive lock on all tables"
issue can (as I wrote in the part of my mail that you sniped) be
solved I think by storing a list of OIDs instead of a flag for the
locks and inval events.

greetings, Florian Pflug

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavan Deolasee 2007-07-23 16:34:05 Re: 8.2 is 30% better in pgbench than 8.3
Previous Message Alvaro Herrera 2007-07-23 16:22:56 Re: 8.2 is 30% better in pgbench than 8.3