From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
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 03:04:08 |
Message-ID: | 27160.1295319848@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Josh Berkus <josh(at)agliodbs(dot)com> writes:
> 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?
If that is happening, autovacuum is screwed anyway. Even if it manages
to acquire the lock, it will get kicked off by the next lock request
before it can finish vacuuming the table. So I don't see an argument
here for adding all the mechanism required to support that.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Jim Nasby | 2011-01-18 03:45:31 | Re: limiting hint bit I/O |
Previous Message | Tom Lane | 2011-01-18 02:48:58 | pg_filedump moved to pgfoundry |