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: 14452.1242319602@sss.pgh.pa.us (view raw or flat)
Thread:
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
example.

FWIW, we have implemented a trial solution to your original complaint
for 8.4:
http://archives.postgresql.org/pgsql-committers/2009-05/msg00208.php

			regards, tom lane

In response to

Responses

pgsql-bugs by date

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

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