Re: [PATCH] add concurrent_abort callback for output plugin

Поиск
Список
Период
Сортировка
От Ajin Cherian
Тема Re: [PATCH] add concurrent_abort callback for output plugin
Дата
Msg-id CAFPTHDZvJOuszdTWZizJ0Ayg6nJiJLM7WMO84MJC7N36smYX2A@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [PATCH] add concurrent_abort callback for output plugin  (Markus Wanner <markus.wanner@enterprisedb.com>)
Ответы Re: [PATCH] add concurrent_abort callback for output plugin  (Markus Wanner <markus.wanner@enterprisedb.com>)
Список pgsql-hackers
Дерево обсуждения


On Tue, Mar 30, 2021 at 5:30 PM Markus Wanner <markus.wanner@enterprisedb.com> wrote:
Hello Ajin,

On 30.03.21 06:48, Ajin Cherian wrote:
> For now, I've created a patch that addresses the problem reported using
> the existing callbacks.

Thanks.

> Do have a look if this fixes the problem reported.

Yes, this replaces the PREPARE I would do from the concurrent_abort
callback in a direct call to rb->prepare.  However, it misses the most
important part: documentation.  Because this clearly is a surprising
behavior for a transaction that's not fully decoded and guaranteed to
get aborted.


Where do you suggest this be documented? From an externally visible point of view, I dont see much of a surprise.
A transaction that was prepared and rolled back can be decoded to be prepared and rolled back with incomplete changes.
Are you suggesting more comments in code?

regards,
Ajin Cherian
Fujitsu Australia

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Pavel Stehule
Дата:
Сообщение: Re: Idea: Avoid JOINs by using path expressions to follow FKs
Следующее
От: "Joel Jacobson"
Дата:
Сообщение: Re: Idea: Avoid JOINs by using path expressions to follow FKs