Re: Instability in postgres_fdw regression tests

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Nathan Bossart <nathandbossart(at)gmail(dot)com>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Instability in postgres_fdw regression tests
Date: 2026-02-10 18:34:37
Message-ID: 3950599.1770748477@sss.pgh.pa.us
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Nathan Bossart <nathandbossart(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Nathan Bossart 2026-02-10 18:45:35 Re: refactor architecture-specific popcount code
Previous Message Alexandre Felipe 2026-02-10 18:19:28 Re: [WIP]Vertical Clustered Index (columnar store extension) - take2