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>, 'Chao Li' <li(dot)evan(dot)chao(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 11:06:27
Message-ID: OS9PR01MB12149C3E3EC7D9738644CEBD8F5BF2@OS9PR01MB12149.jpnprd01.prod.outlook.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Dear Vignesh, Chao,

> Finding #4: Test uses a stale subscription

Not critical, but DROP SUBSCRIPTION might be better to put before the DROP
PUBLICATION. Also related with the test, I feel below lines are not needed.

```
$node_subscriber->safe_psql('postgres', 'DROP SUBSCRIPTION tap_sub');
$node_publisher->safe_psql('postgres', 'DROP PUBLICATION tap_pub1');
$node_publisher->safe_psql('postgres', 'DROP PUBLICATION tap_pub2');

$node_publisher->stop('fast');
```

> > Finding #5: SET UNLOGGED on an excluded table produces an unrestorable
> > catalog state
> However, I have some concern about the design. Since a table in the EXCEPT
> list is not published anyway, do we really need to reject SET UNLOGGED? Would
> it make more sense to remove the table from the EXCEPT list and emit a NOTICE
> to inform the user?

I prefer the Vignesh's idea. For now publications are created with extactly given
settings, but your idea may break the existing rule. Can you raise existing
examples?

Best regards,
Hayato Kuroda
FUJITSU LIMITED

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Vaibhav Dalvi 2026-09-10 11:08:54 Re: Add PRODUCT() aggregate function
Previous Message Xuneng Zhou 2026-09-10 11:02:22 Re: Reject WAIT FOR earlier in transaction-snapshot mode