Re: Failures in constraints regression test, "read only 0 of 8192 bytes"

Thomas Munro <thomas.munro@gmail.com>

From: Thomas Munro <thomas.munro@gmail.com>
To: Heikki Linnakangas <hlinnaka@iki.fi>
Cc: Tomas Vondra <tomas.vondra@enterprisedb.com>, Ronan Dunklau <ronan.dunklau@aiven.io>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2024-03-10T21:32:09Z
Lists: pgsql-hackers
On Mon, Mar 11, 2024 at 9:59 AM Thomas Munro <thomas.munro@gmail.com> wrote:
> On Mon, Mar 11, 2024 at 9:30 AM Heikki Linnakangas <hlinnaka@iki.fi> wrote:
> > Hmm, I'm not sure if we need even smgrreleaseall() here anymore. It's
> > not required for correctness AFAICS. We don't do it in single-rel
> > invalidation in RelationCacheInvalidateEntry() either.
>
> I think we do, because we have missed sinval messages.  It's unlikely
> but a relfilenode might have been recycled, and we might have file
> descriptors that point to the unlinked files.  That is, there are new
> files with the same names and we need to open those ones.

... though I think you would be right if Dilip and Robert had
succeeded in their quest to introduce 56-bit non-cycling relfilenodes.
And for the record, we can also shoot ourselves in the foot in another
known case without sinval[1], so more work is needed here, but that
doesn't mean this sinval code path should also aim footwards.

[1] https://www.postgresql.org/message-id/flat/CA%2BhUKGLs554tQFCUjv_vn7ft9Xv5LNjPoAd--3Df%2BJJKJ7A8kw%40mail.gmail.com#f099d68e95edcfe408818447d9da04a7



Commits

  1. Fix relcache invalidation when relfilelocator is updated

  2. Don't destroy SMgrRelations at relcache invalidation

  3. Add a new slot sync worker to synchronize logical slots.