Thread: synchronized scan: reset state at end of scan

I was looking into supporting synchronized scans for VACUUM, and I
noticed that we currently don't remove the reported scan location as
this post suggests:

http://archives.postgresql.org/pgsql-patches/2007-06/msg00047.php

There was some debate about whether it should be done, but I thought
that the solution here seemed to satisfy most people's concerns:

http://archives.postgresql.org/pgsql-patches/2007-06/msg00052.php

I attached a patch that implements the above idea.

The benefit is that if you have a singular scan, it will start at the
beginning of the heap and not at some arbitrary place.

The cost is that it's not 100% guaranteed that the location entry will
be removed. The backend that started the scan could abort, die, etc.
Also, in rare situations there is a small window created where a new
scan might not be synchronized with existing concurrent scans. This is
really only an issue when issuing queries with limits or issuing two
scans that progress at different rates. I think it's somewhat reasonable
to say that if you're doing either of those things, you shouldn't be too
surprised if it messes with synchronized scanning. I have more
information in the comments in the attached patch.

I do not have a strong opinion about whether this patch is applied or
not. I am submitting this just for the sake of completeness.

Regards,
    Jeff Davis

Jeff Davis <pgsql@j-davis.com> writes:
> I was looking into supporting synchronized scans for VACUUM, and I
> noticed that we currently don't remove the reported scan location as
> this post suggests:

> http://archives.postgresql.org/pgsql-patches/2007-06/msg00047.php

I thought the end conclusion of that thread was to not do anything,
on the grounds that
(1) having new scans sometimes fail to join an existing syncscan
herd would be a bad thing because of the resulting performance
uncertainty;
(2) partially masking the order-nondeterminism created by syncscans
would be a bad thing because it would make it more likely for people
to not notice the issue during testing.

            regards, tom lane

On Sat, 2008-05-31 at 22:01 -0400, Tom Lane wrote:
> I thought the end conclusion of that thread was to not do anything,
> on the grounds that
> (1) having new scans sometimes fail to join an existing syncscan
> herd would be a bad thing because of the resulting performance
> uncertainty;
> (2) partially masking the order-nondeterminism created by syncscans
> would be a bad thing because it would make it more likely for people
> to not notice the issue during testing.

Ok, I certainly am not pushing for this patch to be applied. I'll
consider it closed.

Regards,
    Jeff Davis