Re: One-off failure in "cluster" test

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: One-off failure in "cluster" test
Date: 2020-08-17 01:20:40
Message-ID: 1036193.1597627240@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Munro 2020-08-17 01:27:57 Re: One-off failure in "cluster" test
Previous Message Thomas Munro 2020-08-17 01:03:59 One-off failure in "cluster" test