From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Markus Wanner <markus(dot)wanner(at)enterprisedb(dot)com> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org, amit(dot)kapila16(at)gmail(dot)com, itsajin(at)gmail(dot)com |
Subject: | Re: [PATCH] add concurrent_abort callback for output plugin |
Date: | 2021-03-25 20:21:55 |
Message-ID: | 20210325202155.h6a5hpguslrhsa5x@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 2021-03-25 10:07:28 +0100, Markus Wanner wrote:
> This leads to the possibility of the transaction getting aborted concurrent
> to logical decoding. In that case, it is likely for the decoder to error on
> a catalog scan that conflicts with the abort of the transaction. The
> reorderbuffer sports a PG_CATCH block to cleanup.
FWIW, I am seriously suspicuous of the code added as part of
7259736a6e5b7c75 and plan to look at it after the code freeze. I can't
really see this code surviving as is. The tableam.h changes, the bsyscan
stuff, ... Leaving correctness aside, the code bloat and performance
affects alone seems problematic.
> Again, this callback is especially important for output plugins that invoke
> further actions on downstream nodes that delay the COMMIT PREPARED of a
> transaction upstream, e.g. until prepared on other nodes. Up until now, the
> output plugin has no way to learn about a concurrent abort of the currently
> decoded (2PC or streamed) transaction (perhaps short of continued polling on
> the transaction status).
You may have only meant it as a shorthand: But imo output plugins have
absolutely no business "invoking actions downstream".
> diff --git a/src/backend/replication/logical/reorderbuffer.c b/src/backend/replication/logical/reorderbuffer.c
> index c291b05a423..a6d044b870b 100644
> --- a/src/backend/replication/logical/reorderbuffer.c
> +++ b/src/backend/replication/logical/reorderbuffer.c
> @@ -2488,6 +2488,12 @@ ReorderBufferProcessTXN(ReorderBuffer *rb, ReorderBufferTXN *txn,
> errdata = NULL;
> curtxn->concurrent_abort = true;
>
> + /*
> + * Call the cleanup hook to inform the output plugin that the
> + * transaction just started had to be aborted.
> + */
> + rb->concurrent_abort(rb, txn, streaming, commit_lsn);
> +
> /* Reset the TXN so that it is allowed to stream remaining data. */
> ReorderBufferResetTXN(rb, txn, snapshot_now,
> command_id, prev_lsn,
I don't think this would be ok, errors thrown in the callback wouldn't
be handled as they would be in other callbacks.
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2021-03-25 21:03:36 | Re: ALTER TABLE .. DETACH PARTITION CONCURRENTLY |
Previous Message | Pavel Borisov | 2021-03-25 20:02:03 | Re: [PATCH] Covering SPGiST index |