Re: [PATCH] add concurrent_abort callback for output plugin

From: Ajin Cherian <itsajin(at)gmail(dot)com>
To: Markus Wanner <markus(dot)wanner(at)enterprisedb(dot)com>
Cc: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: [PATCH] add concurrent_abort callback for output plugin
Date: 2021-03-30 07:39:31
Message-ID: CAFPTHDZvJOuszdTWZizJ0Ayg6nJiJLM7WMO84MJC7N36smYX2A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Mar 30, 2021 at 5:30 PM Markus Wanner <
markus(dot)wanner(at)enterprisedb(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Joel Jacobson 2021-03-30 07:47:07 Re: Idea: Avoid JOINs by using path expressions to follow FKs
Previous Message Pavel Stehule 2021-03-30 07:32:14 Re: Idea: Avoid JOINs by using path expressions to follow FKs