Thomas Munro writes:
> 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
> conditio
On Mon, Aug 17, 2020 at 1:27 PM Thomas Munro wrote:
>
> On Mon, Aug 17, 2020 at 1:20 PM Tom Lane wrote:
> > Thomas Munro 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'
On Mon, Aug 17, 2020 at 1:20 PM Tom Lane wrote:
> Thomas Munro 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
Thomas Munro 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' => {
...
