Simon Riggs <[EMAIL PROTECTED]> writes:
> More thought tells me that we should have a
> LockRelationForCatalogUpdate() that uses nearly the same design pattern
> as LockRelationForExtension(). There is no lockmode since we always take
> the lock in exclusive mode.
This works only for updaters that cooperate with the rule, though.
The scenario that is bothering me is a manual UPDATE on a pg_class row
happening concurrently with an operation that wants to apply a
nontransactional update. While that's more or less deprecated, there
are still plenty of people out there who might try it (cf the old trick
for disabling triggers). I don't mind if one or the other operation
fails and rolls back, but silently losing the nontransactional update
would be entirely unacceptable, as it would quickly lead to database
corruption.
The reason I was thinking about heap_lock_tuple is that it might provide
a suitable defense against that case.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
