Re: Relcache refactoring
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Heikki Linnakangas <hlinnaka@iki.fi>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>,
Alexander Lakhin <exclusion@gmail.com>,
jian he <jian.universality@gmail.com>
Date: 2024-11-01T04:19:38Z
Lists: pgsql-hackers
Heikki Linnakangas <hlinnaka@iki.fi> writes: > I was finally able to reproduce this, by running the failing pg_regress > tests concurrently with repeated "vacuum full pg_database" calls. It's > curious that 'prion' failed on the first run after the commit, I was not > able to reproduce it by just running the unmodified regression tests > with -DRELCACHE_FORCE_RELEASE -DCATCACHE_FORCE_RELEASE. > Committed a fix. There was one codepath that was missing a call to > RelationInitPhysicalAddr(relation) after the patch. Just as a note, BF members broadbill and mamushi showed similar symptoms [1][2]. Neither of them use FORCE_RELEASE options AFAICS. I'm guessing appearance of the failure is simply a timing issue. regards, tom lane [1] https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=broadbill&dt=2024-10-31%2013%3A34%3A08 [2] https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=mamushi&dt=2024-10-31%2016%3A08%3A43
Commits
-
Fix refreshing physical relfilenumber on shared index
- b82c877e76e2 18.0 landed
-
Split RelationClearRelation into three different functions
- 2b9b8ebbf8a2 18.0 landed
-
Simplify call to rebuild relcache entry for indexes
- 8e2e2662214a 18.0 landed
-
Fix bugs in vacuum of shared rels, by keeping their relcache entries current.
- a54e1f158779 11.0 cited