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

• Re: ALTER TABLE .. SET SCHEMA lock strength at 2011-01-01 17:17:53 from Simon Riggs

Responses

• Re: ALTER TABLE .. SET SCHEMA lock strength at 2011-01-01 21:24:08 from Peter Eisentraut

pgsql-hackers by date

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