Re: [PATCH] add concurrent_abort callback for output plugin

Markus Wanner <markus.wanner@enterprisedb.com>

From: Markus Wanner <markus.wanner@enterprisedb.com>
To: Ajin Cherian <itsajin@gmail.com>
Cc: Amit Kapila <amit.kapila16@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2021-03-30T08:10:54Z
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



Commits

  1. Avoid sending prepare multiple times while decoding.

  2. Ensure to send a prepare after we detect concurrent abort during decoding.