RE: Test publication.sql racing with subscription.sql might fail due to cache lookup error

From: "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com>
To: 'Zhijie Hou' <houzhijie22(at)gmail(dot)com>
Cc: vignesh C <vignesh21(at)gmail(dot)com>, Alexander Lakhin <exclusion(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: RE: Test publication.sql racing with subscription.sql might fail due to cache lookup error
Date: 2026-10-13 11:27:36
Message-ID: OS7PR01MB18317EE5D74F6BE2B754DCE95F59E2@OS7PR01MB18317.jpnprd01.prod.outlook.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

> I think it's unnecessary to open the table. IIUC, the main goal is to avoid the
> cache lookup error in CacheInvalidateRelcacheByRelid(), and the v1 patch is
> sufficient for that since it uses CacheInvalidateRelcacheByTuple(). The same
> strategy is also used in RemoveRoleFromObjectPolicy() to handle concurrent
> table
> drops.

Oh, right, CacheInvalidateRelcacheByTuple() does not require the additional cache
search. My code tried to serialize these operations, but it may be
overengineering.

Best regards,
Hayato Kuroda
FUJITSU LIMITED

In response to

Browse pgsql-hackers by date

  From Date Subject
Previous Message Amit Kapila 2026-10-13 11:21:32 Re: Fix WITHOUT OVERLAPS multirange with location replication