Re: [PATCH] Provide more information to filter_prepare

Markus Wanner <markus.wanner@enterprisedb.com>

From: Markus Wanner <markus.wanner@enterprisedb.com>
To: Amit Kapila <amit.kapila16@gmail.com>
Cc: "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>, Ajin Cherian <itsajin@gmail.com>
Date: 2021-03-11T09:14:48Z
Lists: pgsql-hackers
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



Commits

  1. Add a xid argument to the filter_prepare callback for output plugins.