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
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 |