Re: LOCK TABLE .. DEFERRABLE

On 1 September 2016 at 21:28, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:

> So the only way to handle multiple locks is to do this roughly the way
> Rod suggests.

I've just been reading the VACUUM code and it turns out that we
already use Rod's mechanism internally. So on that basis it seems fine
to support this as a useful user-level feature. If there is a better
way of doing it, then that can be added later.

My proposed changes to this patch are these

1. Rename this WAIT PATIENTLY, which is IMHO a better description of
what is being requested. Bikeshedding welcome.

2. Introduce a new API call LockTablePatiently() that returns bool. So
its usage is similar to ConditionalLockTable(), the only difference is
you supply some other wait parameters with it. This isolates the
internal mechanism from the usage, so allows us to more easily support
any fancy new way of doing this we think of later.

3. Use LockTablePatiently() within lockcmds.c where appropriate

4. Replace the code for waiting in VACUUM with the new call to
LockTablePatiently()

So I see this as 2 patches: 1) new API and make VACUUM use new API, 2)
Rod's LOCK TABLE patch

First patch attached, requires also lock by Oid. If we agree, Rod,
please update your patch to match?

(I pushed this back to next CF, but we can still go ahead if we complete)

Comments?

--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services