Re: Instability in postgres_fdw regression tests
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Nathan Bossart <nathandbossart@gmail.com>
Cc: pgsql-hackers@lists.postgresql.org
Date: 2026-02-10T18:34:37Z
Lists: pgsql-hackers
Nathan Bossart <nathandbossart@gmail.com> writes: > On Tue, Feb 10, 2026 at 12:06:02PM -0500, Tom Lane wrote: >> It's not clear to me that it's worth running this to ground in any >> more detail than that. The behavior is not wrong; it's the test's >> fault to assume that these rows will be returned in a deterministic >> order. So I think the right fix is to adjust the test query, >> along the lines of >> >> -UPDATE ft2 SET c3 = 'bar' WHERE postgres_fdw_abs(c1) > 2000 RETURNING *; >> +WITH cte AS ( >> + UPDATE ft2 SET c3 = 'bar' WHERE postgres_fdw_abs(c1) > 2000 RETURNING * >> +) SELECT * FROM cte ORDER BY c1; > +1. I faintly recall looking into this a while ago and, for some reason, I > was worried that this would become a game of Whac-A-Mole, so apparently I > didn't follow through. But fixing this query is still an improvement over > the status quo. Yeah, it's certainly fair to wonder where else we have even-lower-probability test interactions. But I don't think getting rid of the interaction is realistic, especially given Alexander's results (which I confess to having forgotten about) that show that autovacuum is involved in this somehow despite being disabled on this particular table. So the answer has to be to make the test case more robust against such things. regards, tom lane
Commits
-
Further stabilize a postgres_fdw test case.
- a3fd53babb8e 19 (unreleased) landed
- ec9f0cbe018a 14.22 landed
- c10535fbea02 15.17 landed
- 946b653b7ab9 18.3 landed
- 8277336992b8 16.13 landed
- 048a9f113d20 17.9 landed