Re: Avoid streaming the transaction which are skipped (in corner cases) - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: Avoid streaming the transaction which are skipped (in corner cases)
Date
Msg-id CAA4eK1KEQtm5thOHpHCYn5gw_jcqnBHSx+oUcwg-gx6Zqz9oVg@mail.gmail.com
Whole thread Raw
In response to Avoid streaming the transaction which are skipped (in corner cases)  (Dilip Kumar <dilipbalaut@gmail.com>)
Responses Re: Avoid streaming the transaction which are skipped (in corner cases)
List pgsql-hackers
On Fri, Nov 25, 2022 at 1:35 PM Dilip Kumar <dilipbalaut@gmail.com> wrote:
>
> During DecodeCommit() for skipping a transaction we use ReadRecPtr to
> check whether to skip this transaction or not.  Whereas in
> ReorderBufferCanStartStreaming() we use EndRecPtr to check whether to
> stream or not. Generally it will not create a problem but if the
> commit record itself is adding some changes to the transaction(e.g.
> snapshot) and if the "start_decoding_at" is in between ReadRecPtr and
> EndRecPtr then streaming will decide to stream the transaction where
> as DecodeCommit will decide to skip it.  And for handling this case in
> ReorderBufferForget() we call stream_abort().
>

The other cases are probably where we don't have FilterByOrigin or
dbid check, for example, XLOG_HEAP2_NEW_CID/XLOG_XACT_INVALIDATIONS.
We anyway actually don't send anything for such cases except empty
start/stop messages. Can we add some flag to txn which says that there
is at least one change like DML that we want to stream? Then we can
use that flag to decide whether to stream or not.

-- 
With Regards,
Amit Kapila.



pgsql-hackers by date:

Previous
From: Ashutosh Bapat
Date:
Subject: Re: Avoid distributing new catalog snapshot again for the transaction being decoded.
Next
From: Peter Eisentraut
Date:
Subject: Re: [DOCS] Stats views and functions not in order?