On 2018-Nov-06, Robert Haas wrote:
> If you don't throw an error when a partition is concurrently detached
> and then someone routes a tuple to that portion of the key space, what
> DO you do? Continue inserting tuples into the table even though it's
> no longer a partition?
Yes -- the table was a partition when the query started, so it's still
a partition from the point of view of that query's snapshot.
> Throw tuples destined for that partition away?
Surely not. (/me doesn't beat straw men anyway.)
> You can make an argument for both of those behaviors, but they're
> both pretty strange. The first one means that for an arbitrarily long
> period of time after detaching a partition, the partition may continue
> to receive inserts that were destined for its former parent.
Not arbitrarily long -- only as long as those old snapshots live. I
don't find this at all surprising.
(I think DETACH is not related to DROP in any way. My proposal is that
DETACH can work concurrently, and if people want to drop the partition
later they can wait until snapshots/queries that could see that
partition are gone.)
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services