From: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
---|---|
To: | Fabrízio Mello <fabriziomello(at)gmail(dot)com> |
Cc: | 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 13:01:47 |
Message-ID: | CAB7nPqSd20JEGH_TseR-UoUidB7BzBJ-DXhD0ZqDpDFaR1E1_Q@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Jul 31, 2015 at 11:41 AM, Fabrízio de Royes Mello wrote:
>> We usually don't compare lock values that way, i.e. there's not
>> guaranteed to be a strict monotonicity between lock levels. I don't
>> really agree with that policy, but it's nonetheless there.
>
> And how is the better way to compare lock values to get the highest lock
> level? Perhaps creating a function to compare lock levels?
I guess that this is exactly what Andres has in mind, aka something
like LockModeCompare(lockmode, lockmode) that returns {-1,0,1}
depending on which lock is higher on the hierarchy. This would do
exactly what your patch is doing though, except that this will
localize the comparison operators in lock.c. Though I am seeing at
quick glance a couple of places already do such comparisons:
backend/commands/tablecmds.c: if (cmd_lockmode > lockmode)
backend/storage/lmgr/lock.c: lockmode > RowExclusiveLock)
backend/storage/lmgr/lock.c: if (lockmode >= AccessExclusiveLock &&
backend/access/heap/heapam.c: Assert(lockmode >= NoLock && lockmode
< MAX_LOCKMODES);
backend/access/heap/heapam.c: Assert(lockmode >= NoLock && lockmode
< MAX_LOCKMODES);
backend/access/heap/heapam.c: Assert(lockmode >= NoLock && lockmode
< MAX_LOCKMODES);
backend/access/index/indexam.c: Assert(lockmode >= NoLock &&
lockmode < MAX_LOCKMODES);
All of them are just sanity checks, except the one in tablecmds.c is
not (2dbbda0). Hence I am thinking that this is not really a problem
this patch should tackle by itself...
Regards,
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Shay Rojansky | 2015-07-31 13:02:23 | Encoding of early PG messages |
Previous Message | Jeremy Harris | 2015-07-31 11:21:54 | Re: Using quicksort and a merge step to significantly improve on tuplesort's single run "external sort" |