Re: logical replication empty transactions - Mailing list pgsql-hackers

From Ajin Cherian
Subject Re: logical replication empty transactions
Date
Msg-id CAFPTHDZVu4G85NeVnjFBMgJChkt4rC5xrVAtd3ABdFpiPDFt0g@mail.gmail.com
Whole thread Raw
In response to Re: logical replication empty transactions  (Amit Kapila <amit.kapila16@gmail.com>)
Responses RE: logical replication empty transactions  ("wangw.fnst@fujitsu.com" <wangw.fnst@fujitsu.com>)
Re: logical replication empty transactions  (Peter Smith <smithpb2250@gmail.com>)
List pgsql-hackers
On Thu, Feb 17, 2022 at 9:42 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
>
> On Mon, Jan 31, 2022 at 6:18 PM Ajin Cherian <itsajin@gmail.com> wrote:
> >
>
> Few comments:
> =============
> 1. Is there any particular why the patch is not skipping empty xacts
> for streaming (in-progress) transactions as noted in the commit
> message as well?
>

I have added support for skipping streaming transaction.

> 2.
> +static void
> +pgoutput_begin(LogicalDecodingContext *ctx, ReorderBufferTXN *txn)
> +{
>   bool send_replication_origin = txn->origin_id != InvalidRepOriginId;
> + PGOutputTxnData *txndata = (PGOutputTxnData *) txn->output_plugin_private;
> +
> + Assert(txndata);
>
> I think here you can add an assert for sent_begin_txn to be always false?
>

Added.

> 3.
> +/*
> + * Send BEGIN.
> + * This is where the BEGIN is actually sent. This is called
> + * while processing the first change of the transaction.
> + */
>
> Have an empty line between the first two lines to ensure consistency
> with nearby comments. Also, the formatting of these lines appears
> awkward, either run pgindent or make sure lines are not too short.
>

Changed.

> 4. Do we really need to make any changes in PREPARE
> transaction-related functions if can't skip in that case? I think you
> can have a check if the output plugin private variable is not set then
> ignore special optimization for sending begin.
>

I have modified this as well.

I have also rebased the patch after it did not apply due to a new commit.

I will next work on testing and improving the keepalive logic while
skipping transactions.

regards,
Ajin Cherian
Fujitsu Australia

Attachment

pgsql-hackers by date:

Previous
From: "Imseih (AWS), Sami"
Date:
Subject: Re: [BUG] Panic due to incorrect missingContrecPtr after promotion
Next
From: "tanghy.fnst@fujitsu.com"
Date:
Subject: RE: Design of pg_stat_subscription_workers vs pgstats