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=p...@mail.gmail.com> I don't see anything in here that addresses the issue structurally? Greetings, Andres Freund
