]> granicus.if.org Git - postgresql/commit
YA attempt to stabilize the results of the postgres_fdw regression test.
authorTom Lane <tgl@sss.pgh.pa.us>
Thu, 12 Apr 2018 19:12:06 +0000 (15:12 -0400)
committerTom Lane <tgl@sss.pgh.pa.us>
Thu, 12 Apr 2018 19:12:14 +0000 (15:12 -0400)
commit2fe977712c7375ccb1b6ddf7dfb234d0db903f16
treeb08fb18cfdf24e2f62f9e0a373af84a206a64335
parenta4d56f583e7cff052c2699e62d867ae1c8fda4f3
YA attempt to stabilize the results of the postgres_fdw regression test.

We've made multiple attempts to stabilize the plans shown by commit
1bc0100d2, with little success so far.  The reason for the remaining
instability seems to be that if a transaction (such as auto-analyze)
is running concurrently with the test, then get_actual_variable_range may
return a maximum value for "T 1"."C 1" that's far away from the actual max,
as a result of our having transiently inserted such a value earlier in
the test.  Because we use a non-MVCC snapshot to fetch the value (for
performance reasons), the presence of other transactions can cause that
function to return entries that are actually dead.

To fix, use a less extreme value in the earlier transient insertion, so
that whether it is visible or not won't affect the selectivity estimate.
The use of 9999 there seems to have been picked with the aid of a
dartboard anyway, rather than having a specific reason.

Discussion: https://postgr.es/m/16962.1523551784@sss.pgh.pa.us
contrib/postgres_fdw/expected/postgres_fdw.out
contrib/postgres_fdw/sql/postgres_fdw.sql