Re: ALTER TABLE .. DETACH PARTITION CONCURRENTLY

On 2021-Apr-27, Amit Langote wrote:

> On Tue, Apr 27, 2021 at 4:34 PM Amit Langote <amitlangote09(at)gmail(dot)com> wrote:

> I think we may need a separate context for partdesc_nodetached, likely
> with the same kludges as rd_pdcxt. Maybe the first problem will go
> away with that as well.

Ooh, seems I completely misunderstood what RelationClose was doing. I
thought it was deleting the whole rd_pdcxt, *including* the "current"
partdesc. But that's not at all what it does: it only deletes the
*children* memcontexts, so the partdesc that is currently valid remains
valid. I agree that your proposed fix appears to be promising, in that
a separate "context tree" rd_pddcxt (?) can be used for this. I'll try
it out now.

> Few other minor things I noticed:
>
> + * Store it into relcache. For snapshots built excluding detached
> + * partitions, which we save separately, we also record the
> + * pg_inherits.xmin of the detached partition that was omitted; this
> + * informs a future potential user of such a cached snapshot.
>
> The "snapshot" in the 1st and the last sentence should be "partdesc"?

Doh, yeah.

> + * We keep two partdescs in relcache: rd_partdesc_nodetached excludes
> + * partitions marked concurrently being detached, while rd_partdesc includes
> + * them.
>
> IMHO, describing rd_partdesc first in the sentence would be better.
> Like: rd_partdesc includes all partitions including any that are being
> concurrently detached, while rd_partdesc_nodetached excludes them.

Makes sense.

--
Álvaro Herrera Valdivia, Chile