Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorHeikki Linnakangas2024-10-31 16:24:48 +0000
committerHeikki Linnakangas2024-10-31 16:24:48 +0000
commitb82c877e76e2398409e823773413079668cf1881 (patch)
tree389793d207f99e506786feb1fc32886880bf4812 /src/backend/utils/cache
parentfb7e27abfbd4e1bae44ce29f5f2c6f6d1aabb5e2 (diff)
Fix refreshing physical relfilenumber on shared index
Buildfarm member 'prion', which is configured with -DRELCACHE_FORCE_RELEASE -DCATCACHE_FORCE_RELEASE, failed with errors like this: ERROR: could not read blocks 0..0 in file "global/2672": read only 0 of 8192 bytes while running a parallel test group that includes VACUUM FULL on some catalog tables among other things. I was not able to reproduce that just by running the tests with -DRELCACHE_FORCE_RELEASE -DCATCACHE_FORCE_RELEASE, even though 'prion' hit it on first run after commit 2b9b8ebbf8, so there might be something else that makes it more susceptible to the race. However, I was able to reproduce it by adding another test to the same test group that runs "vacuum full pg_database" repeatedly. The problem is that RelationReloadIndexInfo() no longer calls RelationInitPhysicalAddr() on a nailed, shared index, when an invalidation happens early during backend startup, before the critical relcaches have been built. Before commit 2b9b8ebbf8, that was done by RelationReloadNailed(), but it went missing from that path. Add it back as an explicit step. Broken by commit 2b9b8ebbf8, which refactored these functions. Discussion: https://www.postgresql.org/message-id/db876575-8f5b-4193-a538-df7e1f92d47a%40iki.fi
Diffstat (limited to 'src/backend/utils/cache')
-rw-r--r--src/backend/utils/cache/relcache.c7
1 files changed, 5 insertions, 2 deletions
diff --git a/src/backend/utils/cache/relcache.c b/src/backend/utils/cache/relcache.c
index 01ffea560a1..5bbb654a5db 100644
--- a/src/backend/utils/cache/relcache.c
+++ b/src/backend/utils/cache/relcache.c
@@ -2253,11 +2253,14 @@ RelationReloadIndexInfo(Relation relation)
* If it's a shared index, we might be called before backend startup has
* finished selecting a database, in which case we have no way to read
* pg_class yet. However, a shared index can never have any significant
- * schema updates, so it's okay to ignore the invalidation signal. Just
- * mark it valid and return without doing anything more.
+ * schema updates, so it's okay to mostly ignore the invalidation signal.
+ * Its physical relfilenumber might've changed, but that's all. Update
+ * the physical relfilenumber, mark it valid and return without doing
+ * anything more.
*/
if (relation->rd_rel->relisshared && !criticalRelcachesBuilt)
{
+ RelationInitPhysicalAddr(relation);
relation->rd_isvalid = true;
return;
}