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
