Re: [PATCH] add concurrent_abort callback for output plugin

From: Markus Wanner <markus(dot)wanner(at)enterprisedb(dot)com>
To: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Ajin Cherian <itsajin(at)gmail(dot)com>
Subject: Re: [PATCH] add concurrent_abort callback for output plugin
Date: 2021-03-29 09:53:20
Message-ID: ffa2ec6a-a096-255f-f442-139764ecaca7@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 29.03.21 11:33, Amit Kapila wrote:
> You don't need an additional callback for that if we do what I am
> suggesting above.

Ah, are you suggesting a different change, then? To make two-phase
transactions always send PREPARE even if concurrently aborted? In that
case, sorry, I misunderstood.

I'm perfectly fine with that approach as well (even though it removes
flexibility compared to the concurrent abort callback, as the comment
above DecodePrepare indicates, i.e. "not impossible to optimize the
concurrent abort case").

> One is you can try to test it, otherwise, there are comments atop
> DecodePrepare() ("Note that we don't skip prepare even if have
> detected concurrent abort because it is quite possible that ....")
> which explains this.

Thanks for this pointer, very helpful.

Regards

Markus

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message 曾文旌 2021-03-29 09:55:05 Re: [Proposal] Global temporary tables
Previous Message Amit Kapila 2021-03-29 09:53:01 Re: [PATCH] Provide more information to filter_prepare