On 03/18/2014 11:39 AM, Simon Riggs wrote:
> On 8 March 2014 11:14, Simon Riggs <si...@2ndquadrant.com> wrote:
>> On 7 March 2014 09:04, Simon Riggs <si...@2ndquadrant.com> wrote:
>>
>>> The right thing to do here is to not push to the extremes. If we mess
>>> too much with the ruleutil stuff it will just be buggy. A more
>>> considered analysis in a later release is required for a full and
>>> complete approach. As I indicated earlier, an 80/20 solution is better
>>> for this release.
>>>
>>> Slimming down the patch, I've removed changes to lock levels for
>>> almost all variants. The only lock levels now reduced are those for
>>> VALIDATE, plus setting of relation and attribute level options.
>>>
>>> VALIDATE is implemented by calling pg_get_constraintdef_mvcc(), a
>>> slightly modified variant of pg_get_constraintdef that uses the
>>> transaction snapshot. I propose this rather than Noah's solution
>>> solely because this will allow any user to request the MVCC data,
>>> rather than implement a hack that only works for pg_dump. I will post
>>> the patch later today.
>> Implemented in attached patch, v22
>>
>> The following commands (only) are allowed with
>> ShareUpdateExclusiveLock, patch includes doc changes.
>>
>> ALTER TABLE ... VALIDATE CONSTRAINT constraint_name
>> covered by isolation test, plus verified manually with pg_dump
>>
>> ALTER TABLE ... ALTER COLUMN ... SET STATISTICS
>> ALTER TABLE ... ALTER COLUMN ... SET (...)
>> ALTER TABLE ... ALTER COLUMN ... RESET (...)
>>
>> ALTER TABLE ... CLUSTER ON ...
>> ALTER TABLE ... SET WITHOUT CLUSTER
>> ALTER TABLE ... SET (...)
>> covered by isolation test
>>
>> ALTER TABLE ... RESET (...)
>>
>> ALTER INDEX ... SET (...)
>> ALTER INDEX ... RESET (...)
>>
>> All other ALTER commands take AccessExclusiveLock
>>
>> I commend this patch to you for final review; I would like to commit
>> this in a few days.
> I'm planning to commit this today at 1500UTC barring objections or
> negative reviews.
At my current level of competence, this patch looks good to me. I'm
looking forward to reading Noah's review to see what I may have missed.
The attached patch fixes two typos in the code comments.
--
Vik
*** a/src/backend/commands/tablecmds.c
--- b/src/backend/commands/tablecmds.c
***************
*** 2939,2945 **** AlterTableGetLockLevel(List *cmds)
/*
* These subcommands affect implicit row type conversion. They
! * have affects similar to CREATE/DROP CAST on queries.
* don't provide for invalidating parse trees as a result of
* such changes, so we keep these at AccessExclusiveLock.
*/
--- 2939,2945 ----
/*
* These subcommands affect implicit row type conversion. They
! * have affects similar to CREATE/DROP CAST on queries. We
* don't provide for invalidating parse trees as a result of
* such changes, so we keep these at AccessExclusiveLock.
*/
*** a/src/backend/utils/cache/relcache.c
--- b/src/backend/utils/cache/relcache.c
***************
*** 1889,1895 **** RelationDestroyRelation(Relation relation, bool remember_tupdesc)
if (--relation->rd_att->tdrefcount == 0)
{
/*
! * If we Rebuilt a relcache entry during a transaction then its
* possible we did that because the TupDesc changed as the result
* of an ALTER TABLE that ran at less than AccessExclusiveLock.
* It's possible someone copied that TupDesc, in which case the
--- 1889,1895 ----
if (--relation->rd_att->tdrefcount == 0)
{
/*
! * If we Rebuilt a relcache entry during a transaction then it's
* possible we did that because the TupDesc changed as the result
* of an ALTER TABLE that ran at less than AccessExclusiveLock.
* It's possible someone copied that TupDesc, in which case the
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
