Re: postgres_fdw regression tests order dependency

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: postgres_fdw regression tests order dependency
Date: 2013-06-09 23:24:51
Message-ID: 16051.1370820291@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andrew Dunstan <andrew(at)dunslane(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Craig Ringer 2013-06-09 23:28:24 Re: Hard limit on WAL space used (because PANIC sucks)
Previous Message Andrew Dunstan 2013-06-09 22:49:06 Re: JSON and unicode surrogate pairs