On Sat, Mar 13, 2021 at 3:43 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
>
> On Thu, Mar 11, 2021 at 2:44 PM Markus Wanner
> <markus.wanner@enterprisedb.com> wrote:
> >
> > On 11.03.21 04:58, Amit Kapila wrote:
> > > But this happens when we are decoding prepare, so it is clear that the
> > > transaction is prepared, why any additional check?
> >
> > An output plugin cannot assume the transaction is still prepared and
> > uncommitted at the point in time it gets to decode the prepare.
> > Therefore, the transaction may or may not be still in progress.
> > However, my point is that the xid is the more generally useful
> > identifier than the gid.
> >
> > > What in this can't be done with GID and how XID can achieve it?
> >
> > It's a convenience. Of course, an output plugin could lookup the xid
> > via the gid. But why force it to have to do that when the xid would be
> > so readily available?
> >
>
> I am not suggesting doing any such look-up. It is just that the use of
> additional parameter(s) for deciding whether to decode at prepare time
> or to decode later as a regular one-phase transaction is not clear to
> me. Now, it is possible that your argument is right that passing
> additional information gives flexibility to plugin authors and we
> should just do what you are saying or maybe go even a step further and
> pass ReorderBufferTxn but I am not completely sure about this point
> because I didn't hear of any concrete use case.
>
During a discussion of GID's in the nearby thread [1], it came up that
the replication solutions might want to generate a different GID based
on xid for two-phase transactions, so it seems this patch has a
use-case.
Markus, feel free to update the docs, you might want to mention about
use-case of XID. Also, feel free to add an open item on PG-14 Open
Items page [2].
[1] - https://www.postgresql.org/message-id/CAA4eK1%2BopiV4aFTmWWUF9h_32%3DHfPOW9vZASHarT0UA5oBrtGw%40mail.gmail.com
[2] - https://wiki.postgresql.org/wiki/PostgreSQL_14_Open_Items
--
With Regards,
Amit Kapila.
