From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: lock level for DETACH PARTITION looks sketchy |
Date: | 2018-12-20 18:13:09 |
Message-ID: | 20181220181309.zrdumz6sndiyz65z@alvherre.pgsql |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | David Rowley | 2018-12-20 19:33:24 | Re: Switching to 64-bit Bitmapsets |
Previous Message | Tom Lane | 2018-12-20 17:44:17 | Performance issue in foreign-key-aware join estimation |