Re: ALTER TABLE .. DETACH PARTITION CONCURRENTLY - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: ALTER TABLE .. DETACH PARTITION CONCURRENTLY
Date
Msg-id 20210421203855.GA19814@alvherre.pgsql
Whole thread Raw
In response to Re: ALTER TABLE .. DETACH PARTITION CONCURRENTLY  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Responses Re: ALTER TABLE .. DETACH PARTITION CONCURRENTLY  (Amit Langote <amitlangote09@gmail.com>)
Re: ALTER TABLE .. DETACH PARTITION CONCURRENTLY  (Noah Misch <noah@leadboat.com>)
List pgsql-hackers
While the approach in the previous email does pass the tests, I think
(but couldn't find a test case to prove) it does so coincidentally, not
because it is correct.  If I make the test for "detached exist" use the
cached omits-partitions-partdesc, it does fail, because we had
previously cached one that was not yet omitting the partition.  So what
I said earlier in the thread stands: the set of partitions that are
considered detached changes depending on what the active snapshot is,
and therefore we *must not* cache any such descriptor.

So I backtracked to my previous proposal, which saves in relcache only
the partdesc that includes all partitions.  If any partdesc is built
that omits partitions being detached, that one must be rebuilt afresh
each time.  And to avoid potentially saving a lot of single-use
partdescs in CacheMemoryContext, in the attached second patch (which I
attach separately only to make it more obvious to review) I store such
partdescs in PortalContext.

Barring objections, I will get this pushed early tomorrow.

-- 
Álvaro Herrera       Valdivia, Chile
"Just treat us the way you want to be treated + some extra allowance
 for ignorance."                                    (Michael Brusser)

Attachment

pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: when the startup process doesn't
Next
From: Tom Lane
Date:
Subject: Re: when the startup process doesn't