On Sun, Apr 24, 2016 at 11:51 AM, Andres Freund <and...@anarazel.de> wrote: > Here's a patch doing so. Note that, after putting the record into RM_XACT_ID > first, I've decided to make it a RM_STANDBY_ID type record. I think it's > likely that this is going to be needed beyond transaction commits, and > it generally seems to fit better into standby.c; even if it's a bit > awkward that commit records contain similar data. To avoid duplicating > the *desc.c code, I've exposed standby_desc_invalidations() to also be > used by xactdesc.c.
I have been eyeballing this patch for some time since yesterday and did some tests, and that's really neat. Having the invalidation stuff in standby.c makes quite some sense as well. + * wanting to emit more WAL recoreds). s/recoreds/records/ > The reason this all ends up working nonetheless is that the > heap_inplace_update()s in vacuum triggers a CacheInvalidateHeapTuple() > which queues a relcache invalidation, which in turn does a > RelationCloseSmgr() in RelationClearRelation(). Thereby effectively > doing a transactional CacheInvalidateSmgr(). But that seems more than > fragile. You have spent quite some time on that. As things stand that's indeed a bit fragile.. > ISTM we should additionally replace the CacheInvalidateSmgr() with a > CacheInvalidateRelcache() and document that that implies an smgr > invalidation. Alternatively we could log smgr (and relmapper) > invalidations as well, but that's not quite non-invasive either; but > might be a good long-term idea to keep things simpler. > > Comments? Yeah, this looks like a good idea at the end. As the invalidation patch is aimed at being backpatched, this may be something to do as well in back-branches. -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
