Re: ALTER TABLE .. DETACH PARTITION CONCURRENTLY
Amit Langote <amitlangote09@gmail.com>
From: Amit Langote <amitlangote09@gmail.com>
To: Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: Justin Pryzby <pryzby@telsasoft.com>, Tom Lane <tgl@sss.pgh.pa.us>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2021-04-26T12:04:55Z
Lists: pgsql-hackers
Hi Alvaro, On Sat, Apr 24, 2021 at 8:31 AM Alvaro Herrera <alvherre@alvh.no-ip.org> wrote: > On 2021-Apr-23, Alvaro Herrera wrote: > > I think the patch I posted was too simple. I think a real fix requires > > us to keep track of exactly in what way the partdesc is outdated, so > > that we can compare to the current situation in deciding to use that > > partdesc or build a new one. For example, we could keep track of a list > > of OIDs of detached partitions (and it simplifies things a lot if allow > > only a single partition in this situation, because it's either zero OIDs > > or one OID); or we can save the Xmin of the pg_inherits tuple for the > > detached partition (and we can compare that Xmin to our current active > > snapshot and decide whether to use that partdesc or not). > > > > I'll experiment with this a little more and propose a patch later today. > > This (POC-quality) seems to do the trick. Thanks for the patch. > (I restored the API of find_inheritance_children, because it was getting > a little obnoxious. I haven't thought this through but I think we > should do something like it.) +1. > > I don't think it's too much of a problem to state that you need to > > finalize one detach before you can do the next one. After all, with > > regular detach, you'd have the tables exclusively locked so you can't do > > them in parallel anyway. (It also increases the chances that people > > will finalize detach operations that went unnoticed.) That sounds reasonable. > I haven't added a mechanism to verify this; but with asserts on, this > patch will crash if you have more than one. I think the behavior is not > necessarily sane with asserts off, since you'll get an arbitrary > detach-Xmin assigned to the partdesc, depending on catalog scan order. Maybe this is an ignorant question but is the plan to add an elog() in this code path or a check (and an ereport()) somewhere in ATExecDetachPartition() to prevent more than one partition ending up in detach-pending state? Please allow me to study the patch a bit more closely and get back tomorrow. -- Amit Langote EDB: http://www.enterprisedb.com
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