On Thu, Jul 8, 2010 at 5:09 PM, Simon Riggs <si...@2ndquadrant.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 <si...@2ndquadrant.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
