Re: One-off failure in "cluster" test - Mailing list pgsql-hackers

From Thomas Munro
Subject Re: One-off failure in "cluster" test
Date
Msg-id CA+hUKGJpCfzdOxwbsfT2fMJqFSQ7rQRtWaMHKav5oJg-J5j_AQ@mail.gmail.com
Whole thread Raw
In response to Re: One-off failure in "cluster" test  (Thomas Munro <thomas.munro@gmail.com>)
Responses Re: One-off failure in "cluster" test  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Mon, Aug 17, 2020 at 1:27 PM Thomas Munro <thomas.munro@gmail.com> wrote:
>
> On Mon, Aug 17, 2020 at 1:20 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > Thomas Munro <thomas.munro@gmail.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',

Ahh, I see what's happening.  You don't need a concurrent process
scanning *your* table for scan order to be nondeterministic.  The
preceding CLUSTER command can leave the start block anywhere if its
call to ss_report_location() fails to acquire SyncScanLock
conditionally.  So I think we just need to disable that for this test,
like in the attached.

Attachment

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Fix an old description in high-availability.sgml
Next
From: Michael Paquier
Date:
Subject: Re: OpenSSL 3.0.0 compatibility