Skip site navigation (1) Skip section navigation (2)

Re: ALTER TABLE .. SET SCHEMA lock strength

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Simon Riggs <simon(at)2ndQuadrant(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: ALTER TABLE .. SET SCHEMA lock strength
Date: 2011-01-01 18:17:46
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Simon Riggs <simon(at)2ndQuadrant(dot)com> writes:
> On Sat, 2011-01-01 at 11:06 -0500, Robert Haas wrote:
>> While reviewing the SQL/MED patch, I happened to notice that
>> ExecAlterObjectSchemaStmt calls AlterTableNamespace with a lock mode
>> argument of AccessExclusiveLock. Does anyone see a reason why
>> ShareUpdateExclusiveLock would be insufficient?

> It seemed unsafe to me to do that while an object was being accessed,
> since it effectively changes the search_path, which is dangerous.

ALTER RENAME and ALTER SET SCHEMA are both in the nature of changing the
object's identity.  Consider the fairly typical use-case where you are
renaming an "old" instance out of the way and renaming another one into
the same schema/name.  Do you really want that to be a low-lock
operation?  I find it really hard to envision a use case where it'd be
smart to allow some concurrent operations to continue using the the old
instance while others start using the new one.

			regards, tom lane

In response to


pgsql-hackers by date

Next:From: Simon RiggsDate: 2011-01-01 19:03:30
Subject: Re: Sync Rep Design
Previous:From: Stefan KaltenbrunnerDate: 2011-01-01 17:49:44
Subject: Re: Sync Rep Design

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group