dropping partitions and concurrent reads

From: Jeff Davis <pgsql(at)j-davis(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: dropping partitions and concurrent reads
Date: 2009-09-15 19:05:11
Message-ID: 1253041511.29243.39.camel@monkey-cat.sm.truviso.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


S1, S2 are concurrent sessions:

S1: create table test_par (v int);
S1: create table test_ch1 (check (v > 0 and v <= 2)) inherits (test_par);
S1: create table test_ch2 (check (v > 2 and v <= 4)) inherits (test_par);
S1: begin;
S1: drop table test_ch1 cascade;

S2: select * from test_par where v = 3;

S1: commit;

in S2 I get:

ERROR: could not open relation with OID 66962

This can happen without partitioning by dropping the table you're
reading. That won't ever be better than an ERROR, because obviously you
can't answer the query without the table.

However it seems to be worse in the case of inheritance/partitioning
because you are dropping a table that you don't need to answer the
select query. Also, it seems like a common use-case for partitioning.

Acquiring an ACCESS EXCLUSIVE lock on the parent is a workaround. Should
we do that when dropping a child table? Or can plan invalidation correct
this?

Regards,
Jeff Davis

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kevin Grittner 2009-09-15 19:06:07 Re: Timestamp to time_t
Previous Message Robert Haas 2009-09-15 19:04:50 Re: WIP: generalized index constraints