From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Greg Stark <gsstark(at)mit(dot)edu> |
Cc: | Jan Wieck <JanWieck(at)yahoo(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com>, PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Lock problem with autovacuum truncating heap |
Date: | 2011-03-28 02:43:55 |
Message-ID: | 18103.1301280235@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Greg Stark <gsstark(at)mit(dot)edu> writes:
> I like all of:
> 1) move the truncating to a new transaction just like we currently do
> toast tables in a separate transaction from the main vacuum.
+1 if we are going to continue the behavior of allowing other
transactions to kick autovac off the exclusive lock. However, if we can
find a way to avoid the need of that, then breaking it into multiple
transactions would just be useless complication (and extra cycles).
In particular, I thought the direction Jan was headed was to release and
reacquire the lock between truncating off limited-size chunks of the
file. If we do that, we probably *don't* want or need to allow autovac
to be booted off the lock more quickly.
> 2) Don't bother trying to truncate if we've been called from
> autovacuum at all.
No, I think that's seriously going in the wrong direction. We are
trying to make autovacuum more useful and transparent, not find new
reasons why people have to use manual vacuuming.
> 3) Scanning backwards 8MB at a time scanning each 8MB forwards instead
> of just going back by block backwards.
Maybe. I'd want to see some experimental evidence justifying the choice
of chunk size; I'm pretty sure this will become counterproductive once
the chunk size is too large.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | YAMAMOTO Takashi | 2011-03-28 03:16:16 | Re: SSI bug? |
Previous Message | Tom Lane | 2011-03-28 02:31:41 | Re: Re: [COMMITTERS] pgsql: Fix plpgsql to release SPI plans when a function or DO block is |