Re: Reducing some DDL Locks to ShareLock

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Simon Riggs <simon(at)2ndQuadrant(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Reducing some DDL Locks to ShareLock
Date: 2008-11-11 00:15:49
Message-ID: 272.1226362549@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Simon Riggs <simon(at)2ndQuadrant(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Gregory Stark 2008-11-11 00:17:01 Re: pg_upgrade project status
Previous Message Simon Riggs 2008-11-11 00:12:44 Re: Walsender process patch v1 for Synch Rep