Re: BUG #18559: Crash after detaching a partition concurrently from another session
Kuntal Ghosh <kuntalghosh.2007@gmail.com>
From: Kuntal Ghosh <kuntalghosh.2007@gmail.com>
To: Alvaro Herrera from 2ndQuadrant <alvherre@alvh.no-ip.org>
Cc: Junwang Zhao <zhjwpku@gmail.com>, Tender Wang <tndrwang@gmail.com>, pgsql-bugs@lists.postgresql.org
Date: 2024-08-15T19:31:49Z
Lists: pgsql-bugs
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Avoid failure to open dropped detached partition
- be73e7008558 15.9 landed
- a6ff329e7b72 16.5 landed
- 52f3de874bbe 18.0 landed
- 3ad4c8615a76 14.14 landed
- 11f1218ce81e 17.0 landed
-
Fix creation of partition descriptor during concurrent detach+drop
- c899c6839f5d 18.0 landed
- 559ae1336e03 12.21 landed
- 5236dcdb62ac 13.17 landed
- 305db95434c9 15.9 landed
- 1b9dd6b05a27 16.5 landed
- 1b4bdf915861 14.14 landed
- 0820f80622ed 17.0 landed
On Tue, Aug 13, 2024 at 11:49 PM Alvaro Herrera from 2ndQuadrant <alvherre@alvh.no-ip.org> wrote: > > That means - after getting the live partitions from > > prune_append_rel_partitions(), by the time the code tries to lock a > > child, it's already dropped. > > Right. > > > However, similar check is not there in expand_partitioned_rtentry(). > > Introducing the same check will fix the issue. But, I don't know how > > it affects the pruning part as this partition couldn't be pruned > > earlier and that's why we're opening the child partition. > > Hmm, we could just remove the partition from the set of live partitions > -- then it should behave the same as if the partition had been pruned. > Something like the attached, perhaps. > Thanks for the patch. LGTM. I've verified that it's fixing the issue. -- Thanks & Regards, Kuntal Ghosh