Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Skip to content

Commit b82c877

Browse files
committed
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 2b9b8eb, 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 2b9b8eb, that was done by RelationReloadNailed(), but it went missing from that path. Add it back as an explicit step. Broken by commit 2b9b8eb, which refactored these functions. Discussion: https://www.postgresql.org/message-id/db876575-8f5b-4193-a538-df7e1f92d47a%40iki.fi
1 parent fb7e27a commit b82c877

File tree

1 file changed

+5
-2
lines changed

1 file changed

+5
-2
lines changed

src/backend/utils/cache/relcache.c

Lines changed: 5 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -2253,11 +2253,14 @@ RelationReloadIndexInfo(Relation relation)
22532253
* If it's a shared index, we might be called before backend startup has
22542254
* finished selecting a database, in which case we have no way to read
22552255
* pg_class yet. However, a shared index can never have any significant
2256-
* schema updates, so it's okay to ignore the invalidation signal. Just
2257-
* mark it valid and return without doing anything more.
2256+
* schema updates, so it's okay to mostly ignore the invalidation signal.
2257+
* Its physical relfilenumber might've changed, but that's all. Update
2258+
* the physical relfilenumber, mark it valid and return without doing
2259+
* anything more.
22582260
*/
22592261
if (relation->rd_rel->relisshared && !criticalRelcachesBuilt)
22602262
{
2263+
RelationInitPhysicalAddr(relation);
22612264
relation->rd_isvalid = true;
22622265
return;
22632266
}

0 commit comments

Comments
 (0)