Re: [PATCH] add concurrent_abort callback for output plugin

From: Markus Wanner <markus(dot)wanner(at)enterprisedb(dot)com>
To: Ajin Cherian <itsajin(at)gmail(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 08:10:54
Message-ID: 4b842054-264a-4e9a-6ece-42641eac7b78@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 30.03.21 09:39, Ajin Cherian wrote:
> Where do you suggest this be documented? From an externally visible
> point of view, I dont see much of a surprise.

If you start to think about the option of committing a prepared
transaction from a different node, the danger becomes immediately
apparent: A subscriber doesn't even know that the transaction is not
complete. How could it possibly know it's futile to COMMIT PREPARE it?
I think it's not just surprising, but outright dangerous to pretend
having prepared the transaction, but potentially miss some of the changes.

(Essentially: do not assume the ROLLBACK PREPARED will make it to the
subscriber. There's no such guarantee. The provider may crash, burn,
and vanish before that happens.)

So I suggest to document this as a caveat for the prepare callback,
because with this patch that's the callback which may be invoked for an
incomplete transaction without the output plugin knowing.

Regards

Markus

In response to

Responses

Browse pgsql-hackers by date

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