Re: One-off failure in "cluster" test

On Mon, Aug 17, 2020 at 1:20 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Thomas Munro <thomas(dot)munro(at)gmail(dot)com> writes:
> > I wonder what caused this[1] one-off failure to see tuples in clustered order:
> > ...
> > I guess a synchronised scan could cause that, but I wouldn't expect one here.
>
> Looking at its configuration, chipmunk uses
>
> 'extra_config' => {
> ...
> 'shared_buffers = 10MB',
>
> which I think means that clstr_4 would be large enough to trigger a
> syncscan. Ordinarily that's not a problem since no other session would
> be touching clstr_4 ... but I wonder whether (a) autovacuum had decided
> to look at clstr_4 and (b) syncscan can trigger on vacuum-driven scans.
> (a) would explain the non-reproducibility.
>
> I kinda think that (b), if true, is a bad idea and should be suppressed.
> autovacuum would typically fail to keep up with other syncscans thanks
> to vacuum delay settings, so letting it participate seems unhelpful.

Yeah, I wondered that as well and found my way to historical
discussions concluding that autovacuum should not participate in sync
scans. Now I'm wondering if either table AM refactoring or parallel
vacuum refactoring might have inadvertently caused that to become a
possibility in REL_13_STABLE.