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 07:06:50 |
Message-ID: | cb471a95-15d2-a9db-d877-a01c2f29a184@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 27.03.21 07:37, Amit Kapila wrote:
> Isn't it better to send prepare from the publisher in such a case so
> that subscribers can know about it when rollback prepared arrives?
That's exactly what this callback allows (among other options). It
provides a way for the output plugin to react to a transaction aborting
while it is being decoded. This would not be possible without this
additional callback.
Also note that I would like to retain the option to do some basic
protocol validity checks. Certain messages only make sense within a
transaction ('U'pdate, 'C'ommit). Others are only valid outside of a
transaction ('B'egin, begin_prepare_cb). This is only possible if the
output plugin has a callback for every entry into and exit out of a
transaction (being decoded). This used to be the case prior to 2PC
decoding and this patch re-establishes that.
> I think we have already done the same (sent prepare, exactly to handle
> the case you have described above) for *streamed* transactions.
Where can I find that? ISTM streaming transactions have the same issue:
the output plugin does not (or only implicitly) learn about a concurrent
abort of the transaction.
Regards
Markus
From | Date | Subject | |
---|---|---|---|
Next Message | Markus Wanner | 2021-03-29 07:27:25 | Re: [PATCH] Provide more information to filter_prepare |
Previous Message | Amit Kapila | 2021-03-29 06:23:52 | Re: [PATCH] Provide more information to filter_prepare |