| From: | Henson Choi <assam258(at)gmail(dot)com> |
|---|---|
| To: | jihyun bahn <rring0727(at)gmail(dot)com>, Mikhail Kharitonov <mikhail(dot)kharitonov(dot)dev(at)gmail(dot)com> |
| Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org, sawada(dot)mshk(at)gmail(dot)com |
| Subject: | Re: [PATCH] Fix replica identity mismatch for partitioned tables with publish_via_partition_root |
| Date: | 2026-06-27 01:11:34 |
| Message-ID: | CAAAe_zAr8k9Uv1+oj2WypaRVsKru5e9rx6PuMtkjukjK=o6yHg@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi Mikhail,
One small design question on the v3 API:
> The old functions remain as wrappers to preserve compatibility.
After the patch, though, the base functions have no callers. The only
call site (the switch in pgoutput_change()) calls the _extended forms
directly, leaving logicalrep_write_update()/logicalrep_write_delete() as
wrappers that just forward the same relation twice; a tree-wide grep
finds no caller, and no contrib output plugin uses them either.
Is there a basis for treating these as an external interface?
They look like pgoutput's internal write-side helpers, paired with the
apply worker's logicalrep_read_* side -- not a documented extension API, and
signatures here change across major versions anyway. Unless they are
commonly called from extensions, formally or informally, I don't see
what the _extended wrapping preserves.
Since there is exactly one caller, with both the leaf and the
publication relation already in scope, it seems simpler to give the base
functions the two-relation signature directly and update that one switch
-- dropping the _extended variants and the wrappers. No behavior change.
Not a blocker; happy to drop this if there's a consumer I'm missing.
Regards,
Henson
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Xuneng Zhou | 2026-06-27 01:56:16 | Re: 048_vacuum_horizon_floor.pl hangs due to wakeup lost inside LockBufferForCleanup |
| Previous Message | Ben Mejia | 2026-06-27 00:59:26 | hashjoins vs. bitmap filters |