Dean, Robert, Afaics the problem described below was introduced in b4e07417, do you have a different/better proposal than s/CacheInvalidateSmgr/CacheInvalidateRelcache/? Doing that doesn't feel quite right either, because it only makes the file extension visible at end-of-xact - which is mostly harmless, but still.
On 2016-04-23 19:51:17 -0700, Andres Freund wrote: > It fixes the problem at hand, but essentially it's just luck that the > patch is sufficient. The first layer of the issue is that queued > invalidation messages aren't sent; but for vm_extend() there's another > side to it. Namely vm_extend() does > > /* > * Send a shared-inval message to force other backends to close any smgr > * references they may have for this rel, which we are about to change. > * This is a useful optimization because it means that backends don't > have > * to keep checking for creation or extension of the file, which happens > * infrequently. > */ > CacheInvalidateSmgr(rel->rd_smgr->smgr_rnode); > > but CacheInvalidateSmgr is non-transactional as it's comment explains: > * > * Note: because these messages are nontransactional, they won't be captured > * in commit/abort WAL entries. Instead, calls to CacheInvalidateSmgr() > * should happen in low-level smgr.c routines, which are executed while > * replaying WAL as well as when creating it. > * > > as far as I can see vm_extend() is the only current caller forgetting > that rule. I don't think it's safe to use CacheInvalidateSmgr() outside > smgr.c. > > 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. > > 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. - Andres -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
