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? (Especially given that seems rather expensive. Or how would an extension lookup the xid by gid?)
The initial versions by Nikhil clearly did include it (actually a full ReorderBufferTXN, which I think would be even better). I'm not clear on your motivations to restrict the API. What's clear to me is that the more information Postgres exposes to plugins and extensions, the easier it becomes to extend Postgres. (Modulo perhaps API stability considerations. A TransactionId clearly is not a concern in that area. Especially given we expose the entire ReorderBufferTXN struct for other callbacks.)
Regards Markus
