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

Re: Is this the expected behaviour for DDL-query execution?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Thomas Johansson <thomas(dot)johansson(at)agama(dot)tv>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: Is this the expected behaviour for DDL-query execution?
Date: 2009-05-14 16:46:42
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-bugs
Thomas Johansson <thomas(dot)johansson(at)agama(dot)tv> writes:
>  So what would be the best/easiest way to circumvent this behaviour 
> while still allowing concurrent queries? I tried to implement a solution 
> which I hoped would fix this by first doing NO INHERIT on the partition 
> which were to be dropped and then later (an hour later, to be absolutely 
> sure that no query were still using the table) dropping the table. 
> However this resulted in the following type of problem instead, which I 
> guess is just another symptom of the locking strategy described by you 
> above?

> ProgrammingError: could not find inherited attribute "id" of relation 
> "state_change_20090429"

What PG version are you using?  In 8.3 it seems to work automatically,
although in prior versions you could well have some problems with cached
plans not getting invalidated.  If it is 8.3 I'd like to see a detailed

FWIW, we have implemented a trial solution to your original complaint
for 8.4:

			regards, tom lane

In response to


pgsql-bugs by date

Next:From: HugoDate: 2009-05-14 17:13:50
Previous:From: Devrim GÜNDÜZDate: 2009-05-14 15:09:51
Subject: Re: POSTGRESQL 8.2.3

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