pgsql: Fix refreshing physical relfilenumber on shared index
От | Heikki Linnakangas |
---|---|
Тема | pgsql: Fix refreshing physical relfilenumber on shared index |
Дата | |
Msg-id | E1t6Y09-003JjV-2Z@gemulon.postgresql.org обсуждение исходный текст |
Список | pgsql-committers |
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 Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/b82c877e76e2398409e823773413079668cf1881 Modified Files -------------- src/backend/utils/cache/relcache.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-)
В списке pgsql-committers по дате отправления: