On Wed, Jun 30, 2021 at 8:56 PM Gurjeet Singh <gurj...@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
