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