Re: [PATCH] Provide more information to filter_prepare

From: Markus Wanner <markus(dot)wanner(at)enterprisedb(dot)com>
To: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Ajin Cherian <itsajin(at)gmail(dot)com>
Subject: Re: [PATCH] Provide more information to filter_prepare
Date: 2021-03-11 09:14:48
Message-ID: fd63284b-14fa-051a-fa51-e6999e8f4502@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2021-03-11 10:03:21 Re: OpenSSL 3.0.0 compatibility
Previous Message Masahiko Sawada 2021-03-11 08:44:37 Performance degradation of REFRESH MATERIALIZED VIEW