Thomas Johansson <thomas.johans...@agama.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 -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
