RE: Review items for EXCEPT TABLE publication

From: "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com>
To: 'vignesh C' <vignesh21(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: RE: Review items for EXCEPT TABLE publication
Date: 2026-09-10 09:41:45
Message-ID: OS9PR01MB121494C1A07EF569BFD383E33F5BF2@OS9PR01MB12149.jpnprd01.prod.outlook.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Dear Vignesh,

> I ran claude to identify issues related to the EXCEPT TABLE
> publication changes.

Very nice. I think this should be part of the community's routine.

> Finding #1: ALTER PUBLICATION race
> Finding #2: ALTER PUBLICATION validates against pre-lock state

To confirm, why can't we acquire the lock at the beginning of AlterPublication()
and re-check the publication state? For now AlterPublicationOptions() acquires
the AccessShareLock only if the row filter and column list may be specified, but
it could cause elog(ERROR, "tuple concurrently updated") error. It cannot be
translated thus may be surprising. Instead, can we obtain AccessExclusive
(or ShareUpdateExclusiveLock, which can block each other) at the beginning to
block concurrent operations?

Best regards,
Hayato Kuroda
FUJITSU LIMITED

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message shveta malik 2026-09-10 09:42:09 Re: Review items for EXCEPT TABLE publication
Previous Message Ashutosh Bapat 2026-09-10 09:41:04 Re: PGQ catalog representation and pg_dump support