| From: | Alexander Lakhin <exclusion(at)gmail(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Instability in postgres_fdw regression tests |
| Date: | 2026-02-10 18:00:00 |
| Message-ID: | d7602a05-dfbd-40d2-9e37-1f7093460da8@gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hello Tom,
10.02.2026 19:06, Tom Lane wrote:
> Several BF animals have intermittently shown this regression diff:
>
> diff -U3 /home/bf/bf-build/culicidae/HEAD/pgsql/contrib/postgres_fdw/expected/postgres_fdw.out /home/bf/bf-build/culicidae/HEAD/pgsql.build/testrun/postgres_fdw-running/regress/results/postgres_fdw.out
> --- /home/bf/bf-build/culicidae/HEAD/pgsql/contrib/postgres_fdw/expected/postgres_fdw.out 2025-12-29 19:48:22.661603936 +0100
> +++ /home/bf/bf-build/culicidae/HEAD/pgsql.build/testrun/postgres_fdw-running/regress/results/postgres_fdw.out 2026-02-10 00:31:31.856460156 +0100
> @@ -6519,6 +6519,7 @@
> UPDATE ft2 SET c3 = 'bar' WHERE postgres_fdw_abs(c1) > 2000 RETURNING *;
> c1 | c2 | c3 | c4 | c5 | c6 | c7 | c8
> ------+----+-----+----+----+----+------------+----
> + 2010 | 0 | bar | | | | ft2 |
> 2001 | 1 | bar | | | | ft2 |
> 2002 | 2 | bar | | | | ft2 |
> 2003 | 3 | bar | | | | ft2 |
> @@ -6528,7 +6529,6 @@
> 2007 | 7 | bar | | | | ft2 |
> 2008 | 8 | bar | | | | ft2 |
> 2009 | 9 | bar | | | | ft2 |
> - 2010 | 0 | bar | | | | ft2 |
> (10 rows)
>
> EXPLAIN (verbose, costs off)
>
> The above is from culicidae [1], and greenfly has shown it a few times
> [2], and here's one from scorpion [3], and crake on a back branch [4],
> and there are a few more in the past 90 days.
FWIW, all the failures of this ilk are tracked at [1].
> It's pretty clear what is happening: the rows we are looking at are
> being returned by a seqscan, and they were just inserted a few lines
> above into a table that has been modified multiple times already.
> So the test is reliant on them being inserted in sequence at the
> end of the table, yet sometimes the last row is going into free
> space someplace earlier.
>
> One's first instinct is to blame autovacuum, but the test already
> goes out of its way to disable that:
>
> -- Disable autovacuum for these tables to avoid unexpected effects of that
> ALTER TABLE "S 1"."T 1" SET (autovacuum_enabled = 'false');
I reproduced and reported the failure before, please look at [2] —
probably some information there could be helpful...
[1] https://wiki.postgresql.org/wiki/Known_Buildfarm_Test_Failures#postgres_fdw.sql_might_fail_due_to_autovacuum
[2] https://www.postgresql.org/message-id/flat/867266ef-3dd1-44a9-a203-27cb5d2be58d%40gmail.com
Best regards,
Alexander
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2026-02-10 18:15:01 | Re: PGPROC alignment (was Re: pgsql: Separate RecoveryConflictReasons from procsignals) |
| Previous Message | Nathan Bossart | 2026-02-10 17:58:23 | Re: Instability in postgres_fdw regression tests |