| 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
| 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 |