From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Josh Berkus <josh(at)agliodbs(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: We need to log aborted autovacuums |
Date: | 2011-01-18 02:12:13 |
Message-ID: | AANLkTi=7uuNgVWamzJpC_Ma9GYDwpAvcp5uA0AibL1=Y@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Jan 17, 2011 at 8:26 PM, Josh Berkus <josh(at)agliodbs(dot)com> wrote:
> On 1/17/11 11:46 AM, Tom Lane wrote:
>> Do we actually need a lock timeout either? The patch that was being
>> discussed just involved failing if you couldn't get it immediately.
>> I suspect that's sufficient for AV. At least, nobody's made a
>> compelling argument why we need to expend a very substantially larger
>> amount of work to do something different.
>
> The argument is that a sufficiently busy table might never get
> autovacuumed *at all*, whereas a small lock wait would allow autovacuum
> to block incoming transactions and start work.
>
> However, it's hard for me to imagine a real-world situation where a
> table would be under repeated full-table-locks from multiple
> connections. Can anyone else?
I'm not convinced we need a lock timeout for autovacuum. I think it'd
be useful to expose on a user-level, but that's a different can of
worms.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Fujii Masao | 2011-01-18 02:14:59 | Re: pg_basebackup for streaming base backups |
Previous Message | Robert Haas | 2011-01-18 02:11:14 | Re: estimating # of distinct values |