Re: ALTER TABLE .. DETACH PARTITION CONCURRENTLY
Alvaro Herrera <alvherre@alvh.no-ip.org>
From: Álvaro Herrera <alvherre@alvh.no-ip.org>
To: Amit Langote <amitlangote09@gmail.com>
Cc: Justin Pryzby <pryzby@telsasoft.com>, Tom Lane <tgl@sss.pgh.pa.us>, "pgsql-hackers@lists.postgresql.org" <pgsql-hackers@lists.postgresql.org>
Date: 2021-05-06T17:13:47Z
Lists: pgsql-hackers
On 2021-Apr-30, Amit Langote wrote: > The case I was looking at is when a partition detach appears as > in-progress to a serializable transaction. Yeah, I was exceedingly sloppy on my reasoning about this, and you're right that that's what actually happens rather than what I said. > If the caller wants to omit detached partitions, such a partition ends > up in rd_partdesc_nodetached, with the corresponding xmin being set to > 0 due to the way find_inheritance_children_extended() sets > *detached_xmin. The next query in the transaction that wants to omit > detached partitions, seeing rd_partdesc_nodetached_xmin being invalid, > rebuilds the partdesc, again including that partition because the > snapshot wouldn't have changed, and so on until the transaction ends. > Now, this can perhaps be "fixed" by making > find_inheritance_children_extended() set the xmin outside the > snapshot-checking block, but maybe there's no need to address this on > priority. Hmm. See below. > Rather, a point that bothers me a bit is that we're including a > detached partition in the partdesc labeled "nodetached" in this > particular case. Maybe we should avoid that by considering in this > scenario that no detached partitions exist for this transactions and > so initialize rd_partdesc, instead of rd_partdesc_nodetached. That > will let us avoid the situations where the xmin is left in invalid > state. Maybe like the attached (it also fixes a couple of > typos/thinkos in the previous commit). Makes sense -- applied, thanks. > Note that we still end up in the same situation as before where each > query in the serializable transaction that sees the detach as > in-progress to have to rebuild the partition descriptor omitting the > detached partitions, even when it's clear that the detach-in-progress > partition will be included every time. Yeah, you're right that there is a performance hole in the case where a partition pending detach exists and you're using repeatable read transactions. I didn't see it as terribly critical since it's supposed to be very transient, but I may be wrong. -- Álvaro Herrera Valdivia, Chile "Hay quien adquiere la mala costumbre de ser infeliz" (M. A. Evans)
Commits
-
Make detach-partition-concurrently-4 less timing sensitive
- eb43bdbf5104 14.0 landed
-
Improve documentation on DETACH PARTITION lock levels
- db6e1aeb952e 14.0 landed
-
Track detached partitions more accurately in partdescs
- 3fe773b14975 14.0 landed
-
Allow a partdesc-omitting-partitions to be cached
- d6b8d29419df 14.0 landed
-
Fix relcache inconsistency hazard in partition detach
- 8aba9322511f 14.0 landed
-
Don't add a redundant constraint when detaching a partition
- 7b357cc6ae55 14.0 landed
-
ALTER TABLE ... DETACH PARTITION ... CONCURRENTLY
- 71f4c8c6f74b 14.0 landed
-
Let ALTER TABLE Phase 2 routines manage the relation pointer
- cd03c6e94b09 14.0 landed
-
Check default partitions constraints while descending
- f481d2823297 14.0 landed
- ef1e1250e716 12.5 landed
- d0230a43fcae 13.0 landed