Horton
Menu

Thread

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Remove unnecessary break in pg_logical_replication_slot_advance()

  1. Remove extraneous break condition in logical slot advance function

    Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com> — 2023-10-21T02:30:00Z

    Hi,

There exists an extraneous break condition in
pg_logical_replication_slot_advance(). When the end of WAL or moveto
LSN is reached, the main while condition helps to exit the loop, so no
separate break condition is needed. Attached patch removes it.

Thoughts?

-- 
Bharath Rupireddy
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com

  2. Re: Remove extraneous break condition in logical slot advance function

    Gurjeet Singh <gurjeet@singh.im> — 2023-10-21T16:56:15Z

    On Fri, Oct 20, 2023 at 7:30 PM Bharath Rupireddy
<bharath.rupireddyforpostgres@gmail.com> wrote:
>
> Hi,
>
> There exists an extraneous break condition in
> pg_logical_replication_slot_advance(). When the end of WAL or moveto
> LSN is reached, the main while condition helps to exit the loop, so no
> separate break condition is needed. Attached patch removes it.
>
> Thoughts?

+1 for the patch.

The only advantage I see of the code as it stands right now is that it
avoids one last call to CHECK_FOR_INTERRUPTS() by break'ing early. I
don't think we'd lose much in terms of performance by making one (very
cheap, in common case) extra call of this macro.

Best regards,
Gurjeet
http://Gurje.et

  3. Re: Remove extraneous break condition in logical slot advance function

    Tom Lane <tgl@sss.pgh.pa.us> — 2023-10-21T18:10:09Z

    Gurjeet Singh <gurjeet@singh.im> writes:
> On Fri, Oct 20, 2023 at 7:30 PM Bharath Rupireddy
> <bharath.rupireddyforpostgres@gmail.com> wrote:
>> There exists an extraneous break condition in
>> pg_logical_replication_slot_advance(). When the end of WAL or moveto
>> LSN is reached, the main while condition helps to exit the loop, so no
>> separate break condition is needed. Attached patch removes it.

> The only advantage I see of the code as it stands right now is that it
> avoids one last call to CHECK_FOR_INTERRUPTS() by break'ing early. I
> don't think we'd lose much in terms of performance by making one (very
> cheap, in common case) extra call of this macro.

Agreed, bypassing the last CHECK_FOR_INTERRUPTS() shouldn't save
anything noticeable.  Could there be a correctness argument for it
though?  Can't see what.  We should assume that CFIs might happen
down inside LogicalDecodingProcessRecord.

I wondered why the code looks like this, and whether there used
to be more of a reason for it.  "git blame" reveals the probable
answer: when this code was added, in 9c7d06d60, the loop
condition was different so the break was necessary.
38a957316 simplified the loop condition to what we see today,
but didn't notice that the break was thereby made pointless.

While we're here ... the comment above the loop seems wrong
already, and this makes it more so.  I suggest something like

-		/* Decode at least one record, until we run out of records */
+		/* Decode records until we reach the requested target */
		while (ctx->reader->EndRecPtr < moveto)

			regards, tom lane

  4. Re: Remove extraneous break condition in logical slot advance function

    Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com> — 2023-10-22T18:29:00Z

    On Sat, Oct 21, 2023 at 11:40 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Gurjeet Singh <gurjeet@singh.im> writes:
> > On Fri, Oct 20, 2023 at 7:30 PM Bharath Rupireddy
> > <bharath.rupireddyforpostgres@gmail.com> wrote:
> >> There exists an extraneous break condition in
> >> pg_logical_replication_slot_advance(). When the end of WAL or moveto
> >> LSN is reached, the main while condition helps to exit the loop, so no
> >> separate break condition is needed. Attached patch removes it.
>
> > The only advantage I see of the code as it stands right now is that it
> > avoids one last call to CHECK_FOR_INTERRUPTS() by break'ing early. I
> > don't think we'd lose much in terms of performance by making one (very
> > cheap, in common case) extra call of this macro.
>
> Agreed, bypassing the last CHECK_FOR_INTERRUPTS() shouldn't save
> anything noticeable.  Could there be a correctness argument for it
> though?  Can't see what.  We should assume that CFIs might happen
> down inside LogicalDecodingProcessRecord.

AFAICS, there's no correctness argument for breaking before CFI. As
rightly said, CFIs can happen before the break condition either down
inside LogicalDecodingProcessRecord or XLogReadRecord (page_read
callbacks for instance).

Having said that, what may happen if CFI happens and interrupts are
processed before the break condition is that the decoding occurs again
which IMV is not a big problem.

An idea to keep all of  XLogReadRecord() -
LogicalDecodingProcessRecord() loops consistent is by having CFI at
the start of the loops before the XLogReadRecord().

> I wondered why the code looks like this, and whether there used
> to be more of a reason for it.  "git blame" reveals the probable
> answer: when this code was added, in 9c7d06d60, the loop
> condition was different so the break was necessary.
> 38a957316 simplified the loop condition to what we see today,
> but didn't notice that the break was thereby made pointless.

Right. Thanks for these references.

> While we're here ... the comment above the loop seems wrong
> already, and this makes it more so.  I suggest something like
>
> -               /* Decode at least one record, until we run out of records */
> +               /* Decode records until we reach the requested target */
>                 while (ctx->reader->EndRecPtr < moveto)

+1 and done so in the attached v2 patch.

-- 
Bharath Rupireddy
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com

  5. Re: Remove extraneous break condition in logical slot advance function

    Michael Paquier <michael@paquier.xyz> — 2023-10-23T01:24:30Z

    On Sun, Oct 22, 2023 at 11:59:00PM +0530, Bharath Rupireddy wrote:
> AFAICS, there's no correctness argument for breaking before CFI. As
> rightly said, CFIs can happen before the break condition either down
> inside LogicalDecodingProcessRecord or XLogReadRecord (page_read
> callbacks for instance).
> 
> Having said that, what may happen if CFI happens and interrupts are
> processed before the break condition is that the decoding occurs again
> which IMV is not a big problem.
> 
> An idea to keep all of  XLogReadRecord() -
> LogicalDecodingProcessRecord() loops consistent is by having CFI at
> the start of the loops before the XLogReadRecord().

Passing by..  All that just looks like an oversight of 38a957316d7e
that simplified the main while loop, so I've just applied your v2.
--
Michael