From: | Markus Wanner <markus(dot)wanner(at)enterprisedb(dot)com> |
---|---|
To: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Ajin Cherian <itsajin(at)gmail(dot)com> |
Subject: | Re: [PATCH] Provide more information to filter_prepare |
Date: | 2021-03-29 09:41:05 |
Message-ID: | 86f51dc5-a667-c22d-4644-f5fa7ce97f98@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 29.03.21 11:13, Amit Kapila wrote:
> This might or might not be valid for all logical replication solutions
> but in the publisher-subscriber model, it would easily lead to
> duplicate identifiers and block the replication. For example, when
> there are multiple subscriptions (say - 2) for multiple publications
> (again say-2), the two subscriptions are on Node-B and two
> publications are on Node-A. Say both publications are for different
> tables tab-1 and tab-2. Now, a prepared transaction involving
> operation on both tables will generate the same GID.
I think you are misunderstanding. This is about a globally unique
identifier for a transaction, which has nothing to do with a GID used to
prepare a transaction. This *needs* to be the same for what logical is
the same transaction.
What GID a downsteam subscriber uses when receiving messages from some
non-Postgres-provided output plugin clearly is out of scope for this
documentation. The point is to highlight how the xid can be useful for
filter_prepare. And that serves transaction identification purposes.
Regards
Markus
From | Date | Subject | |
---|---|---|---|
Next Message | Rahila Syed | 2021-03-29 09:45:40 | Re: row filtering for logical replication |
Previous Message | Arne Roland | 2021-03-29 09:38:12 | Re: Rename of triggers for partitioned tables |