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

  1. Fix refreshing physical relfilenumber on shared index

  2. Split RelationClearRelation into three different functions

  3. Simplify call to rebuild relcache entry for indexes

  4. Fix bugs in vacuum of shared rels, by keeping their relcache entries current.