Re: Reducing some DDL Locks to ShareLock - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Reducing some DDL Locks to ShareLock
Date
Msg-id 272.1226362549@sss.pgh.pa.us
Whole thread Raw
In response to Re: Reducing some DDL Locks to ShareLock  (Simon Riggs <simon@2ndQuadrant.com>)
Responses Re: Reducing some DDL Locks to ShareLock  (Simon Riggs <simon@2ndQuadrant.com>)
List 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 by date:

Previous
From: Simon Riggs
Date:
Subject: Re: Walsender process patch v1 for Synch Rep
Next
From: Gregory Stark
Date:
Subject: Re: pg_upgrade project status