Re: Force streaming every change in logical decoding - Mailing list pgsql-hackers

From Dilip Kumar
Subject Re: Force streaming every change in logical decoding
Date
Msg-id CAFiTN-vStPYB48vZkjF=4NpMzThTfme=DBm1g+0cRghthxAPMQ@mail.gmail.com
Whole thread Raw
In response to RE: Force streaming every change in logical decoding  ("shiy.fnst@fujitsu.com" <shiy.fnst@fujitsu.com>)
List pgsql-hackers
On Wed, Dec 14, 2022 at 2:15 PM shiy.fnst@fujitsu.com
<shiy.fnst@fujitsu.com> wrote:

> > -    while (rb->size >= logical_decoding_work_mem * 1024L)
> > +    while ((!force_stream && rb->size >= logical_decoding_work_mem *
> > 1024L) ||
> > +           (force_stream && rb->size > 0))
> >      {
> >
> > It seems like if force_stream is on then indirectly it is enabling
> > force serialization as well.  Because once we enter into the loop
> > based on "force_stream" then it will either stream or serialize but I
> > guess we do not want to force serialize based on this parameter.
> >
>
> Agreed, I refactored the code and modified this point.

After thinking more on this I feel the previous behavior made more
sense.  Because without this patch if we cross the work_mem we try to
stream and if we can not stream for some reason e.g. partial change
then we serialize.  And I feel your previous patch was mimicking the
same behavior for each change.  Now in the new patch, we will try to
stream and if we can not we will queue the change so I feel we are
creating a new patch that actually doesn't exist without the force
mode.

-- 
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: Time delayed LR (WAS Re: logical replication restrictions)
Next
From: Dilip Kumar
Date:
Subject: Re: Force streaming every change in logical decoding