Hi,
On Mon, Nov 2, 2026 at 10:36 AM mingjiegaowrote:
I've attached lr01.sql, a minimal psql reproducer for this issue. It
uses separate publisher and subscriber databases in the same instance
and waits for replication between updates.
On an affected build, the final query returns (1,111) and (222,2),
instead of (1,111) and (2,222).
Please run it on a test instance with logical replication enabled and
authentication configured for the subscription connection.
Thanks for the report and patch.
I think the proposed fix is good if the reported scenario (where two
independent published tables route changes to the same subscriber leaf
partition) is rare in practice, since the apply worker won't have to
frequently free and rebuild the cached entry. Even so, maybe it would be
worth adding a comment noting that this case is rare enough that the
rebuild overhead is not a concern.
Just in case, could you share whether you have a real-world use case for
this setup? If this is not a rare case and performance matters here, we
might want to consider changing the LogicalRepPartMap hash key from
(local partoid) to (remoteid + local partoid) so that separate cache
entries are maintained for each remote relation. (I personally don't
have a common usecase for this)
Regarding the tests in the patch, I think it is unnecessary to test both
binary = true and binary = false, as the binary option is unrelated to
the partition mapping logic. We shall keep the test simple, fast and
focused on the reported case.
--
Best Regards,
Zhijie Hou
