Re: ALTER TABLE SET STATISTICS requires AccessExclusiveLock

On Thu, Jul 8, 2010 at 5:09 PM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> On Thu, 2010-07-08 at 06:08 -0400, Robert Haas wrote:
>> On Thu, Jul 8, 2010 at 2:16 AM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
>> > On Wed, 2010-07-07 at 22:26 -0400, Robert Haas wrote:
>> >> Rereading the thread, I'm a bit confused by why we're proposing to use
>> >> a SHARE lock; it seems to me that a self-conflicting lock type would
>> >> simplify things.  There's a bunch of discussion on the thread about
>> >> how to handle pg_class updates atomically, but doesn't using a
>> >> self-conflicting lock type eliminate that problem?
>> >
>> > The use of the SHARE lock had nothing to do with the pg_class update
>> > requirement, so that suggestion won't help there.
>>
>> Forgive me if I press on this just a bit further, but ISTM that an
>> atomic pg_class update functionality isn't intrinsically required,
>> because if it were the current code would need it.  So what is
>> changing in this patch that makes it necessary when it isn't now?
>> ISTM it must be that the lock is weaker.  What am I missing?
>
> Not sure I follow that logic. Discussion on the requirement is in the
> archives. I don't wish to question that aspect myself.

The relevant link from the archives is here:

http://archives.postgresql.org/pgsql-hackers/2008-10/msg00242.php

Tom asked what happens when two transactions attempt to do concurrent
actions on the same table. Your response was that we should handle it
like CREATE INDEX, and handle the update of the pg_class row
non-transactionally. But of course, if you use a self-conflicting
lock at the relation level, then the relation locks conflict and you
never have to worry about how to update the pg_class entry in the face
of concurrent updates.

Which, come to think of it, is probably a good thing, because on
further reflection I'm pretty sure the proposed approach will fall
down completely for some of these operations. heap_inplace_update()
can only be used when (a) the new tuple is identical in size to the
old tuple, and (b) no action is required on rollback. That's fine for
updating things like relpages and reltuples (which are just hints
anyway) but it ain't gonna work for changing, say, reloptions, which
is variable-length. It's also not going to work for changing things
like attstorage, even though a change there can't affect the tuple
size, because modifying the tuple in place won't handle rollbacks
correctly.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company