On 17 July 2018 at 19:47, Robert Haas <robertmhaas@gmail.com> wrote:
> On Mon, Jul 9, 2018 at 6:00 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
>> Proposal would be to add a new lock mode "ShareUpdate", which does not
>> conflict with itself and yet conflicts with "ShareUpdateExclusive" or
>> higher. (Hence, it is a strong lock type). DDL would take a
>> ShareUpdateLock on the table, then during critical portions of
>> commands it would take a ShareUpdateExclusiveLock and then release it
>> again before commit.
>
> I think this would be quite prone to deadlocks. Suppose someone tries
> to grab an AccessExclusiveLock on the table during a window in which
> we hold only ShareUpdateLock. The next attempt to upgrade to
> ShareUpdateExclusiveLock will cause a simple deadlock. In general,
> any approach that involves upgrading our lock strength is likely to
> have this problem.
>
> You might be able to work around this by inventing a whole new lock
> type, say "Relation Maintenance". Make a rule that you can only take
> the "Relation Maintenance" lock while holding a Relation lock with
> strength >= ShareUpdateLock and that you do not need to bother
> acquiring it if you hold a self-exclusive lock that conflicts with
> ShareUpdateLock. I think that works out to about the same thing as
> what you're proposing, except without the deadlock hazard.
Yes, it seems better to invent a new orthogonal lock type than have a
new lock level. Thanks.
Seems more like a critical section than a lock.
I'd make code take that lock, even if they have a self-exclusive lock,
just to avoid later problems when the lock level changes.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services