Re: Error while altering an inheritance hierarchy in mid-query

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bob Lunney <bob_lunney(at)yahoo(dot)com>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: Error while altering an inheritance hierarchy in mid-query
Date: 2010-03-18 19:26:32
Message-ID: 15850.1268940392@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Bob Lunney <bob_lunney(at)yahoo(dot)com> writes:
> 1. A select into query is run which summarizes the data from a partition into a table outside the inheritance hierarchy, which is then indexed.
> 2. Then
> a. a transaction is begun,
> b. the original partition is dropped,
> c. the new table renamed to the original partition's name,
> d. the new table's unique index is renamed,
> e. the appropriate check constraint is added,
> f. select privilege is granted, and
> g. the transaction is committed.

I'd suggest taking an exclusive lock on the inheritance hierarchy's
parent table between 2a and 2b. The "could not open relation with OID
nnn" error is to be expected when a table is dropped just as a query
is in the act of trying to open it, which is what could happen here if
a query on the parent table runs concurrently with the DROP.
You're also at risk that a concurrent query might see both or neither
of the old and new versions of the partition, leading to bogus answers.
Both of these things would be fixed if incoming queries are blocked
while trying to open the parent table, rather than while iterating
through the list of inheritance children for it.

regards, tom lane

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Bob Lunney 2010-03-19 03:22:14 Re: Error while altering an inheritance hierarchy in mid-query
Previous Message Bob Lunney 2010-03-18 19:15:45 Error while altering an inheritance hierarchy in mid-query