Re: [PATCH] add concurrent_abort callback for output plugin
От | Markus Wanner |
---|---|
Тема | Re: [PATCH] add concurrent_abort callback for output plugin |
Дата | |
Msg-id | cb471a95-15d2-a9db-d877-a01c2f29a184@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: [PATCH] add concurrent_abort callback for output plugin (Amit Kapila <amit.kapila16@gmail.com>) |
Ответы |
Re: [PATCH] add concurrent_abort callback for output plugin
|
Список | 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
В списке pgsql-hackers по дате отправления: