| 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: | Whole Thread | Raw Message | 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
| 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 |