Re: Autovacuum stuck for hours, blocking queries

From: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
To: Merlin Moncure <mmoncure(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Tim Bellis <Tim(dot)Bellis(at)metaswitch(dot)com>, Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>, "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com>
Subject: Re: Autovacuum stuck for hours, blocking queries
Date: 2017-02-22 21:19:11
Message-ID: CAMkU=1x39uYXw5oc_8J-jsW8jVWWF=RpMV25gQ=C0Gu5udicsw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Mon, Feb 20, 2017 at 5:40 PM, Merlin Moncure <mmoncure(at)gmail(dot)com> wrote:

>
>
> On Thursday, February 16, 2017, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
>> Tim Bellis <Tim(dot)Bellis(at)metaswitch(dot)com> writes:
>> > Even though this is a read only query, is it also expected to be
>> blocked behind the vacuum? Is there a way of getting indexes for a table
>> which won't be blocked behind a vacuum?
>>
>> It's not the vacuum that's blocking your read-only queries. It's the
>> ALTER TABLE, which needs an exclusive lock in order to alter the table's
>> schema. The ALTER is queued waiting for the vacuum to finish, and lesser
>> lock requests queue up behind it. We could let the non-exclusive lock
>> requests go ahead of the ALTER, but that would create a severe risk of the
>> ALTER *never* getting to run.
>>
>> I'd kill the ALTER and figure on trying again after the vacuum is done.
>>
>>
> I've been drilled by this and similar lock stacking issues enough times to
> make me near 100% sure deferring the ALTER would be the better choice
>
>
This seems like a rather one-sided observation. How could you know how
often the unimplemented behavior also would have "drilled" you, since it is
unimplemented?

There was a proposal for a "LOCK TABLE...DEFERABLE" which would allow other
requestors jump the queue if they were compatible with the held lock. If
that is implemented, then you would just manually lock the table deferably
before invoking the ALTER TABLE command, if that is the behavior you wanted
(but it wouldn't work for things that can't be run in transactions)

Ideally each requestor would specify if they will hold the lock for a long
timer or a short time. Them a short requestor which is blocked behind a
long requestor could let other compatible-with-held requests jump over it.
But once it was only blocked by short locks, it would reassert the normal
order, so it can't get permanently blocked by a constantly overlapping
stream of short locks. But how would you get all lock requestors to
provide a reasonable estimate?

Cheers,

Jeff

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Rob Brucks 2017-02-22 22:05:42 Re: NOTIFY command impact
Previous Message Tom Lane 2017-02-22 21:19:06 Re: NOTIFY command impact