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
-
Avoid sending prepare multiple times while decoding.
- f25a4584c6f5 14.0 landed
-
Ensure to send a prepare after we detect concurrent abort during decoding.
- 4778826532a6 14.0 landed