Re: postgres_fdw regression tests order dependency - Mailing list pgsql-hackers

From Tom Lane
Subject Re: postgres_fdw regression tests order dependency
Date
Msg-id 16051.1370820291@sss.pgh.pa.us
Whole thread Raw
In response to postgres_fdw regression tests order dependency  (Andrew Dunstan <andrew@dunslane.net>)
List pgsql-hackers
Andrew Dunstan <andrew@dunslane.net> writes:
> It looks like the postgres_fdw's regression tests expect data back from 
> the following statement in a given order, which presumably isn't guaranteed:

>     UPDATE ft2 SET c2 = c2 + 600 WHERE c1 % 10 = 8 RETURNING *;

> See 
> <http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=frogmouth&dt=2013-06-08%2018%3A30%3A00>

I think what happened here is that autovacuum ran while the test was in
process, and freed up some space near the start of the table that was
then used by the two INSERTs just above this.  I was able to duplicate
that diff by adding a VACUUM "S 1"."T 1" command just ahead of the
INSERTs.

> Maybe we need to wrap this in a CTE and then order the results for 
> consistency?

In principle, we'd have to do that to every update in the test, which
doesn't seem either painless or conducive to thorough testing.  What I'm
a bit inclined to do instead is to modify the test case so that the rows
inserted by the two INSERTs aren't touched by this UPDATE.  It's
probably easier to guarantee that no rows are updated twice in this test
sequence than to make the query results totally order-independent.

I'm going to go experiment with adding more VACUUMs to the test script
just to see if any other results change ...
        regards, tom lane



pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: JSON and unicode surrogate pairs
Next
From: Craig Ringer
Date:
Subject: Re: Hard limit on WAL space used (because PANIC sucks)