On 8 August 2018 at 01:29, Andres Freund <and...@anarazel.de> wrote: > One approach would be to make sure that everything relying on > rt_partdesc staying the same stores its value in a local variable, and > then *not* free the old version of rt_partdesc (etc) when the refcount > > 0, but delay that to the RelationClose() that makes refcount reach > 0. That'd be the start of a framework for more such concurrenct > handling.
This is not a fully baked idea, but I'm wondering if a better way to do this, instead of having this PartitionIsValid macro to determine if the partition should be visible to the current transaction ID, we could, when we invalidate a relcache entry, send along the transaction ID that it's invalid from. Other backends when they process the invalidation message they could wipe out the cache entry only if their xid is >= the invalidation's "xmax" value. Otherwise, just tag the xmax onto the cache somewhere and always check it before using the cache (perhaps make it part of the RelationIsValid macro). This would also require that we move away from SnapshotAny type catalogue scans in favour of MVCC scans so that backends populating their relcache build it based on their current xid. Unless I'm mistaken, it should not make any difference for all DDL that takes an AEL on the relation, since there can be no older transactions running when the catalogue is modified, but for DDL that's not taking an AEL, we could effectively have an MVCC relcache. It would need careful thought about how it might affect CREATE INDEX CONCURRENTLY and all the other DDL that can be performed without an AEL. I'm unsure how this would work for the catcache as I've studied that code in even less detail, but throwing this out there in case there some major flaw in this idea so that I don't go wasting time looking into it further. I think the PartitionIsValid idea was not that great as it really complicates run-time partition pruning since it's quite critical about partition indexes being the same between the planner and executor. -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
