Re: ALTER TABLE lock strength reduction patch is unsafe Reply-To:

On 21 March 2014 16:11, Simon Riggs <simon@2ndquadrant.com> wrote:

>>> + * Be careful to ensure this function is called for Tables and Indexes only.
>>> + * It is not currently safe to be called for Views because security_barrier
>>> + * is listed as an option and so would be allowed to be set at a level lower
>>> + * than AccessExclusiveLock, which would not be correct.
>>
>> This statement is accepted and takes only ShareUpdateExclusiveLock:
>>
>>   alter table information_schema.triggers set (security_barrier = true);

>> I suggest adding a LOCKMODE field to relopt_gen and adding a
>> reloptions_locklevel() function to determine the required level from an
>> options list.  That puts control of the lock level near the code that
>> understands the implications for each option.  You can then revert the
>> addition of AlterViewInternal() and some of the utility.c changes.
>
> Sure, that's how we code it, but I'm not sure we should introduce that
> feature. The above weirdness is not itself justification.

OK, will follow this path. It's a good idea since it encourages
authors of new "options" to consider properly the lock level that will
be required.

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