On Sat, Mar 13, 2021 at 3:43 PM Amit Kapila <amit.kapil...@gmail.com> wrote: > > On Thu, Mar 11, 2021 at 2:44 PM Markus Wanner > <markus.wan...@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.
