Re: Perform streaming logical transactions by background workers and parallel apply - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: Perform streaming logical transactions by background workers and parallel apply
Date
Msg-id CAA4eK1Ja9P+KUKibF_14Tv-+-mqU9+QW2RdH6PagjrQfAX3Tvw@mail.gmail.com
Whole thread Raw
In response to Re: Perform streaming logical transactions by background workers and parallel apply  (Masahiko Sawada <sawada.mshk@gmail.com>)
List pgsql-hackers
On Thu, Dec 1, 2022 at 11:44 AM Masahiko Sawada <sawada.mshk@gmail.com> wrote:
>
> On Wed, Nov 30, 2022 at 7:54 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
> >
> > On Tue, Nov 29, 2022 at 10:18 AM houzj.fnst@fujitsu.com
> > <houzj.fnst@fujitsu.com> wrote:
> > >
> > > Attach the new version patch which addressed all comments.
> > >
> >
> > Some comments on v53-0002*
> > ========================
> > 1. I think testing the scenario where the shm_mq buffer is full
> > between the leader and parallel apply worker would require a large
> > amount of data and then also there is no guarantee. How about having a
> > developer GUC [1] force_apply_serialize which allows us to serialize
> > the changes and only after commit the parallel apply worker would be
> > allowed to apply it?
>
> +1
>
> The code coverage report shows that we don't cover the partial
> serialization codes. This GUC would improve the code coverage.
>

Shall we keep it as a boolean or an integer? Keeping it as an integer
as suggested by Kuroda-San [1] would have an added advantage that we
can easily test the cases where serialization would be triggered after
sending some changes.

[1] -
https://www.postgresql.org/message-id/TYAPR01MB5866160DE81FA2D88B8F22DEF5159%40TYAPR01MB5866.jpnprd01.prod.outlook.com

-- 
With Regards,
Amit Kapila.



pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: File API cleanup
Next
From: John Naylor
Date:
Subject: Re: [PoC] Improve dead tuple storage for lazy vacuum