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. Anyone else would like to weigh in here? -- With Regards, Amit Kapila.
