From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
---|---|
To: | Fabrízio de Royes Mello <fabriziomello(at)gmail(dot)com> |
Cc: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Doubt about AccessExclusiveLock in ALTER TABLE .. SET ( .. ); |
Date: | 2015-07-31 20:00:12 |
Message-ID: | 20150731200012.GC2441@postgresql.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Fabrízio de Royes Mello wrote:
> In this patch I didn't change all lockmode comparison places previous
> pointed by you, but I can change it maybe adding other method called
> LockModeIsValid(lockmode) to do the comparison "lockmode >= NoLock &&
> lockmode < MAX_LOCKMODES" used in many places.
I don't like this. Is it possible to write these comparisons in terms
of what they conflict with? I think there are two main cases in the
existing code:
1. "is this lock mode valid" (sounds reasonable)
2. "can this be acquired in hot standby" (not so much, but makes
sense.)
and now we have your third thing, "what is the strongest of these two
locks". For instance, if you told me to choose between ShareLock and
ShareUpdateExclusiveLock I wouldn't know which one is strongest. I
don't it's sensible to have the "lock mode compare" primitive honestly.
I don't have any great ideas to offer ATM sadly.
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Kevin Grittner | 2015-07-31 20:21:15 | Re: brin index vacuum versus transaction snapshots |
Previous Message | Alvaro Herrera | 2015-07-31 19:45:24 | Re: brin index vacuum versus transaction snapshots |