| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Dilip Kumar <dilipbalaut(at)gmail(dot)com> |
| Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
| Subject: | Re: Replace is_publishable_class() with relispublishable column in pg_class |
| Date: | 2025-12-16 17:45:17 |
| Message-ID: | fpepoh22dwjlnhn6v7f5ksicxqmtxy6scvfqkjrrcdjytmn2hk@chy5pcp26ln4 |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
On 2025-12-16 11:28:11 -0500, Andres Freund wrote:
> On 2025-12-16 21:19:21 +0530, Dilip Kumar wrote:
> > 2) As suggested by Amit Kpila [2], for the upcoming Conflict Log Table
> > feature, we need a clean way to exclude these internal conflict log
> > tables from publication. A catalog flag allows us to set this property
> > at relation creation rather than adding more special cases.
>
> Seems like the issue here also could be addressed the same way?
Actually, wouldn't a table-level property be completely inappropriate for
that? Imagine one publication that's used for HA (or major version upgrade)
and doesn't use a conflict table, which replicates all tables (including the
conflict table of another pub/sub). And a subscription doing bi-direction
replication that *does* obviously use the conflict table. In one of those
cases you want to replicate changes to the conflict table, in the other
not. So a table / pg_class property would be inappropriate, no?
Greetings,
Andres Freund
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Christoph Berg | 2025-12-16 17:54:46 | Re: failed NUMA pages inquiry status: Operation not permitted |
| Previous Message | Jacob Champion | 2025-12-16 17:40:44 | Re: [oauth] Stabilize the libpq-oauth ABI (and allow alternative implementations?) |