Re: ATTACH/DETACH PARTITION CONCURRENTLY
Andres Freund <andres@anarazel.de>
From: Andres Freund <andres@anarazel.de>
To: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Cc: David Rowley <david.rowley@2ndquadrant.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Simon Riggs <simon@2ndquadrant.com>
Date: 2018-08-10T02:18:00Z
Lists: pgsql-hackers
Hi, On 2018-08-09 20:57:35 +0200, Peter Eisentraut wrote: > On 07/08/2018 15:29, Andres Freund wrote: > > I don't think that solves the problem that an arriving relcache > > invalidation would trigger a rebuild of rd_partdesc, while it actually > > is referenced by running code. > > The problem is more generally that a relcache invalidation changes all > pointers that might be in use. I don't think that's quite right. We already better be OK with superfluous invals that do not change anything, because there's already sources of those (just think of vacuum, analyze, relation extension, whatnot). > So it's currently not safe to trigger a relcache invalidation (on > tables) without some kind of exclusive lock. I don't think that's true in a as general sense as you're stating it. It's not OK to send relcache invalidations for things that people rely on, and that cannot be updated in-place. Because of the dangling pointer issue etc. The fact that currently it is not safe to *change* partition related stuff without an AEL and how to make it safe is precisely what I was talking about in the thread. It won't be a general solution, but the infrastructure I'm talking about should get us closer. > One possible solution to this is outlined here: > <https://www.postgresql.org/message-id/CA+TgmobtmFT5g-0dA=vEFFtogjRAuDHcYPw+qEdou5dZPnF=pg@mail.gmail.com> I don't see anything in here that addresses the issue structurally? Greetings, Andres Freund
Commits
-
Allow ATTACH PARTITION with only ShareUpdateExclusiveLock.
- 898e5e3290a7 12.0 landed
-
Change lock acquisition order in expand_inherited_rtentry.
- f4b6341d5fcb 12.0 landed
-
Move code for managing PartitionDescs into a new file, partdesc.c
- 1bb5e7821810 12.0 landed
-
Remove more redundant relation locking during executor startup.
- f2343653f5b2 12.0 cited
-
Add assertions that we hold some relevant lock during relation open.
- b04aeb0a053e 12.0 cited
-
Try to acquire relation locks in RangeVarGetRelid.
- 4240e429d0c2 9.2.0 cited