Re: Reducing some DDL Locks to ShareLock
От | Tom Lane |
---|---|
Тема | Re: Reducing some DDL Locks to ShareLock |
Дата | |
Msg-id | 272.1226362549@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Reducing some DDL Locks to ShareLock (Simon Riggs <simon@2ndQuadrant.com>) |
Ответы |
Re: Reducing some DDL Locks to ShareLock
|
Список | pgsql-hackers |
Simon Riggs <simon@2ndQuadrant.com> 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
В списке pgsql-hackers по дате отправления: