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