MIME-Version: 1.0
References: <CALj2ACVfF2Uj9NoFy-5m98HNtjHpuD17EDE9twVeJng-jTAe7A@mail.gmail.com>
 <CAPsk3_CzLbMe-D07H5Vo6yWFvyXHh5is7AoPUCFcztrUmf1haw@mail.gmail.com>
 <CALj2ACVzL4uU=hxFpSfkqP4HeFCPucbBTEg6HNf_MPTYm52pHg@mail.gmail.com>
 <CAMm1aWYa1fGKcuG69xGJPNXLQ_9zHrPqhr-ZGdj4so6Exq66MQ@mail.gmail.com> <CALj2ACXa-2eEHHaNRwjcF1k9rtH=EJrWvbGJkucdSOD3zP-OUw@mail.gmail.com>
In-Reply-To: <CALj2ACXa-2eEHHaNRwjcF1k9rtH=EJrWvbGJkucdSOD3zP-OUw@mail.gmail.com>
From: Jingtang Zhang <mrdrivingduck@gmail.com>
Date: Tue, 15 Oct 2024 16:22:32 +0800
Message-ID: <CAPsk3_A7079UtVqm2WXXiwadGJ7DucpenmLwnXZgDgXee703Rw@mail.gmail.com>
Subject: Re: Use WALReadFromBuffers in more places
To: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>, 
	pgsql-hackers@lists.postgresql.org
Cc: Nitin Jadhav <nitinjadhavpostgres@gmail.com>
Content-Type: multipart/alternative; boundary="0000000000005f716c06247fa853"
Archived-At: <https://www.postgresql.org/message-id/CAPsk3_A7079UtVqm2WXXiwadGJ7DucpenmLwnXZgDgXee703Rw%40mail.gmail.com>
Precedence: bulk

--0000000000005f716c06247fa853
Content-Type: text/plain; charset="UTF-8"

Hi all.

I've been back to this patch for a while recently. I witness that if a WAL
writer works fast, the already flushed WAL buffers will be zeroed out and
re-initialized for future use by AdvanceXLInsertBuffer in
XLogBackgroundFlush, so that WALReadFromBuffers will miss even though the
space of WAL buffer is enough. It is much more unfriendly for logical
walsenders than physical walsenders, because logical ones consume WAL
slower than physical ones due to the extra decoding phase. Seems that the
aim
of AdvanceXLInsertBuffer in WAL writer contradicts with our reading from
WAL buffer. Any thoughts?

--0000000000005f716c06247fa853
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><div>Hi all.</div><div><br></div><div>I&#=
39;ve been back to this patch for a while recently. I witness that if a WAL=
</div><div>writer works fast, the already flushed WAL buffers will be zeroe=
d out and</div><div>re-initialized for future use by AdvanceXLInsertBuffer =
in</div><div>XLogBackgroundFlush, so that WALReadFromBuffers will miss even=
 though the</div><div>space of WAL buffer is enough. It is much more unfrie=
ndly for logical</div><div>walsenders than physical walsenders, because log=
ical ones consume=C2=A0WAL</div><div>slower than physical ones due to the e=
xtra decoding phase. Seems that the aim</div><div>of AdvanceXLInsertBuffer =
in WAL writer contradicts with our reading from</div><div>WAL buffer. Any t=
houghts?</div></div></div>

--0000000000005f716c06247fa853--