| From: | Robert Haas <robertmhaas(at)gmail(dot)com> | 
|---|---|
| To: | Peter Eisentraut <peter_e(at)gmx(dot)net> | 
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Simon Riggs <simon(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org | 
| Subject: | Re: ALTER TABLE .. SET SCHEMA lock strength | 
| Date: | 2011-01-01 22:17:17 | 
| Message-ID: | AANLkTinbHx=gqscD2EOtBvD_-r=N8EdoPCp2q1_G0p4x@mail.gmail.com | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-hackers | 
On Sat, Jan 1, 2011 at 4:24 PM, Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:
> On lör, 2011-01-01 at 13:17 -0500, Tom Lane wrote:
>> 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.
>
> At least in Unix land, that's a handy property.  And we're frequently
> cursing those other operating systems where it doesn't work that way.
Yeah, exactly.  If someone is renaming an old instance out of the way
and sticking a new one in its place, the LAST thing you want to do is
lock out queries unnecessarily.
-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2011-01-01 22:21:38 | Re: and it's not a bunny rabbit, either | 
| Previous Message | Peter Eisentraut | 2011-01-01 21:28:34 | Re: and it's not a bunny rabbit, either |