On Wed, Jun 30, 2021 at 8:56 PM Gurjeet Singh <gurjeet@singh.im> wrote:
> As mentioned in that thread, when sending a cancellation signal, the
> client cannot be sure if the cancel signal was honored, and if the
> transaction was cancelled successfully. In the attached patch, the
> backend emits a NotificationResponse containing the current full
> transaction id. It does so only if the relevant GUC is enabled, and
> when the top-transaction is being assigned the ID.
There's nothing to keep a client that wants this information from just
using SELECT txid_current() to get it, so this doesn't really seem
worth it to me. It's true that it could be convenient for someone not
to need to issue an SQL query to get the information and instead just
get it automatically, but I don't think that minor convenience is
enough to justify a new feature of this type.
Also, your 8-line documentation changes contains two spelling
mistakes, and you've used // comments which are not project style in
two places. It's a good idea to check over your patches for such
simple mistakes before submitting them.
--
Robert Haas
EDB: http://www.enterprisedb.com