Re: lock level for DETACH PARTITION looks sketchy

On 2018-Dec-20, Robert Haas wrote:

> One problem about which I thought is the partition check constraint.
> When we attach, we need to validate that the check constraint holds of
> every row in the partition, which means that we need to keep new rows
> from being added while we're attaching. But when we detach, there's
> no corresponding problem. If we detach a leaf partition, the check
> constraint just disappears; if we detach an intermediate partitioned
> table, the check constraint loses some clauses. Either way, there's
> no way for a row that was previously acceptable to become unacceptable
> after the detach operation. There is, however, the possibility that
> the invalidation messages generated by the detach operation might not
> get processed immediately by other backends, so those backends might
> continue to enforce the partition constraint for some period of time
> after it changes. That seems OK.

Check.

> There would be trouble, though, if
> we freed the old copy of the partition constraint during a relcache
> rebuild while somebody still had a pointer to it. I'm not sure that
> can happen, though.

(Reading the pg10 source) AFAICS the partition constraint is stored in
resultRelInfo->ri_PartitionCheck, not affected by relcache invals, so it
seems fine. We also read a copy of it at plan time for constraint
exclusion purposes, similarly not affected by relcache inval.

--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services