Re: Sync scan & regression tests

From: David Rowley <dgrowleyml(at)gmail(dot)com>
To: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
Cc: Melanie Plageman <melanieplageman(at)gmail(dot)com>, Konstantin Knizhnik <knizhnik(at)garret(dot)ru>, pgsql-hackers(at)lists(dot)postgresql(dot)org, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
Subject: Re: Sync scan & regression tests
Date: 2023-08-30 21:15:03
Message-ID: CAApHDvoUqwCPYTHnkMNT1dXTHOv_0gNt2GGDvnmeQaooEeLtqg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, 29 Aug 2023 at 22:35, Heikki Linnakangas <hlinnaka(at)iki(dot)fi> wrote:
> Looking the new heapgettup_advance_block() function and the code that it
> replaced, it's now skipping this ss_report_location() on the last call,
> when it has reached the end of the scan:
>
> >
> > /*
> > * Report our new scan position for synchronization purposes. We
> > * don't do that when moving backwards, however. That would just
> > * mess up any other forward-moving scanners.
> > *
> > * Note: we do this before checking for end of scan so that the
> > * final state of the position hint is back at the start of the
> > * rel. That's not strictly necessary, but otherwise when you run
> > * the same query multiple times the starting position would shift
> > * a little bit backwards on every invocation, which is confusing.
> > * We don't guarantee any specific ordering in general, though.
> > */
> > if (scan->rs_base.rs_flags & SO_ALLOW_SYNC)
> > ss_report_location(scan->rs_base.rs_rd, block);
>
> The comment explicitly says that we do that before checking for
> end-of-scan, but that commit moved it to after. I propose the attached
> to move it back to before the end-of-scan checks.
>
> Melanie, David, any thoughts?

I just looked at v15's code and I agree that the ss_report_location()
would be called even when the scan is finished. It wasn't intentional
that that was changed in v16, so I'm happy for your patch to be
applied and backpatched to 16. Thanks for digging into that.

David

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Nathan Bossart 2023-08-30 21:56:48 Re: pg_stat_get_backend_subxact() and backend IDs?
Previous Message Jacob Champion 2023-08-30 20:55:24 Re: [PATCH] Support SK_SEARCHNULL / SK_SEARCHNOTNULL for heap-only scans