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
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 |