From: | Markus Wanner <markus(at)bluegap(dot)ch> |
---|---|
To: | Ajin Cherian <itsajin(at)gmail(dot)com>, 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 11:29:43 |
Message-ID: | 9069e3b9-c051-d4eb-a6f9-e077cba8f02e@bluegap.ch |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 30.03.21 11:12, Ajin Cherian wrote:
> I found some documentation that already was talking about concurrent
> aborts and updated that.
Thanks.
I just noticed as of PG13, concurrent_abort is part of ReorderBufferTXN,
so it seems the prepare_cb (or stream_prepare_cb) can actually figure a
concurrent abort happened (and the transaction may be incomplete).
That's good and indeed makes an additional callback unnecessary.
I recommend giving a hint to that field in the documentation as well.
> diff --git a/doc/src/sgml/logicaldecoding.sgml b/doc/src/sgml/logicaldecoding.sgml
> index 80eb96d..d2f8d39 100644
> --- a/doc/src/sgml/logicaldecoding.sgml
> +++ b/doc/src/sgml/logicaldecoding.sgml
> @@ -545,12 +545,14 @@ CREATE TABLE another_catalog_table(data text) WITH (user_catalog_table = true);
> executed within that transaction. A transaction that is prepared for
> a two-phase commit using <command>PREPARE TRANSACTION</command> will
> also be decoded if the output plugin callbacks needed for decoding
> - them are provided. It is possible that the current transaction which
> + them are provided. It is possible that the current prepared transaction which
> is being decoded is aborted concurrently via a <command>ROLLBACK PREPARED</command>
> command. In that case, the logical decoding of this transaction will
> - be aborted too. We will skip all the changes of such a transaction once
> - the abort is detected and abort the transaction when we read WAL for
> - <command>ROLLBACK PREPARED</command>.
> + be aborted too. All the changes of such a transaction is skipped once
typo: changes [..] *are* skipped, plural.
> + the abort is detected and the <function>prepare_cb</function> callback is invoked.
> + This could result in a prepared transaction with incomplete changes.
... "in which case the <literal>concurrent_abort</literal> field of the
passed <literal>ReorderBufferTXN</literal> struct is set.", as a proposal?
> + This is done so that eventually when the <command>ROLLBACK PREPARED</command>
> + is decoded, there is a corresponding prepared transaction with a matching gid.
> </para>
>
> <note>
Everything else sounds good to me.
Regards
Markus
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Kapila | 2021-03-30 11:30:53 | Re: extra semicolon in postgres_fdw test cases |
Previous Message | Amit Kapila | 2021-03-30 11:23:56 | Re: row filtering for logical replication |