On Mon, Feb 20, 2017 at 5:40 PM, Merlin Moncure <mmoncure@xxxxxxxxx> wrote:
On Thursday, February 16, 2017, Tom Lane <tgl@xxxxxxxxxxxxx> wrote:Tim Bellis <Tim.Bellis@xxxxxxxxxxxxxx> 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
