From: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Gregory Stark <stark(at)enterprisedb(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Stefan Kaltenbrunner <stefan(at)kaltenbrunner(dot)cc>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: curious regression failures |
Date: | 2007-09-24 05:28:21 |
Message-ID: | 20070924052821.GF5661@alvh.no-ip.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
Tom Lane wrote:
> Idle thought here: did anything get done with the idea of decoupling
> main-table vacuum decisions from toast-table vacuum decisions? vacuum.c
> comments
>
> * Get a session-level lock too. This will protect our access to the
> * relation across multiple transactions, so that we can vacuum the
> * relation's TOAST table (if any) secure in the knowledge that no one is
> * deleting the parent relation.
>
> and it suddenly occurs to me that we'd need some other way to deal with
> that scenario if autovac tries to vacuum toast tables independently.
Hmm, right. We didn't change this in 8.3 but it looks like somebody
will need to have a great idea before long.
Of course, the easy answer is to grab a session-level lock for the main
table while vacuuming the toast table, but it doesn't seem very
friendly.
> Also, did you see the thread complaining that autovacuums block CREATE
> INDEX? This seems true given the current locking definitions, and it's
> a bit annoying. Is it worth inventing a new table lock type just for
> vacuum?
Hmm. I think Jim is right in that what we need is to make some forms of
ALTER TABLE take a lighter lock, one that doesn't conflict with analyze.
Guillaume's complaint are about restore times, which can only be
affected by analyze, not vacuum.
--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
From | Date | Subject | |
---|---|---|---|
Next Message | Brendan Jurd | 2007-09-24 06:33:22 | Bytea as C string in pg_convert? |
Previous Message | Derek E. Lewis | 2007-09-24 05:26:25 | Re: GCC builtins for atomic-test-and-set, memory barries, and such |
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2007-09-24 06:01:24 | actualised SQL/PSM patch |
Previous Message | Andrew Dunstan | 2007-09-24 01:30:33 | Re: remove convert using |