Re: LOCK TABLE .. DEFERRABLE - Mailing list pgsql-hackers

From Rod Taylor
Subject Re: LOCK TABLE .. DEFERRABLE
Date
Msg-id CAKddOFDMAKotegGqdOAqS1OBvW_C5XQZjjRAKh-pML7pfZeCdQ@mail.gmail.com
Whole thread Raw
In response to Re: LOCK TABLE .. DEFERRABLE  (Simon Riggs <simon@2ndQuadrant.com>)
Responses Re: LOCK TABLE .. DEFERRABLE  (Simon Riggs <simon@2ndquadrant.com>)
List pgsql-hackers


On Tue, Apr 5, 2016 at 1:10 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
If a lock is successfully obtained on one table, but not on all tables, it releases that lock and will retry to get them as a group in the future. Since inheritance acts as a group of tables (top + recursive cascade to children), this implementation is necessary even if only a single table is specified in the command.

I'd prefer to see this as a lock wait mode where it sits in the normal lock queue BUT other lock requestors are allowed to queue jump past it. That should be just a few lines changed in the lock conflict checker and some sleight of hand in the lock queue code.

That way we avoid the busy-wait loop and multiple DEFERRABLE lock waiters queue up normally.

Yeah, that would be better. I can see how to handle a single structure in that way but I'm not at all certain how to handle multiple tables and inheritance is multiple tables even with a single command.

X1 inherits from X

There is a long-running task on X1.

Someone requests LOCK TABLE X IN ACCESS EXCLUSIVE MODE WAIT PATIENTLY. Internally this also grabs X1.

The lock on X might be granted immediately and now blocks all other access to that table.

There would need be a Locking Group kind of thing so various LockTags are treated as a single entity to grant them simultaneously. That seems pretty invasive; at least I don't see anything like that today.

pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: LOCK TABLE .. DEFERRABLE
Next
From: Abhijit Menon-Sen
Date:
Subject: Re: dealing with extension dependencies that aren't quite 'e'