Re: Avoid distributing new catalog snapshot again for the transaction being decoded. - Mailing list pgsql-hackers

From Ashutosh Bapat
Subject Re: Avoid distributing new catalog snapshot again for the transaction being decoded.
Date
Msg-id CAExHW5tadBo0ba2nD1b54GirFwXU_dH-Q2fseQmoVQ45EwKcwA@mail.gmail.com
Whole thread Raw
In response to Avoid distributing new catalog snapshot again for the transaction being decoded.  ("houzj.fnst@fujitsu.com" <houzj.fnst@fujitsu.com>)
Responses Re: Avoid distributing new catalog snapshot again for the transaction being decoded.
List pgsql-hackers
Hi Hou,
Thanks for the patch. With a simple condition, we can eliminate the
need to queueing snapshot change in the current transaction and then
applying it. Saves some memory and computation. This looks useful.

When the queue snapshot change is processed in
ReorderBufferProcessTXN(), we call SetupHistoricSnapshot(). But I
didn't find a path through which SetupHistoricSnapshot() is called
from SnapBuildCommitTxn(). Either I missed some code path or it's not
needed. Can you please enlighten me?

-- 
Best Wishes,
Ashutosh Bapat

On Fri, Nov 25, 2022 at 2:28 PM houzj.fnst@fujitsu.com
<houzj.fnst@fujitsu.com> wrote:
>
> Hi,
>
> When doing some other related work, I noticed that when decoding the COMMIT
> record via SnapBuildCommitTxn()-> SnapBuildDistributeNewCatalogSnapshot() we
> will add a new snapshot to all transactions including the one being decoded(just committed one).
>
> But since we've already done required modifications in the snapshot for the
> current transaction being decoded(in SnapBuildCommitTxn()), so I think we can
> avoid adding a snapshot for it again.
>
> Here is the patch to improve this.
> Thoughts ?
>
> Best regards,
> Hou zhijie
>



pgsql-hackers by date:

Previous
From: "Hayato Kuroda (Fujitsu)"
Date:
Subject: RE: [Proposal] Add foreign-server health checks infrastructure
Next
From: Amit Kapila
Date:
Subject: Re: Avoid streaming the transaction which are skipped (in corner cases)