Re: Test tidscan,sql is not immune to autovacuum in v14

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: David Rowley <dgrowleyml(at)gmail(dot)com>
Cc: Alexander Lakhin <exclusion(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Test tidscan,sql is not immune to autovacuum in v14
Date: 2026-08-20 02:50:49
Message-ID: 3530859.1787194249@sss.pgh.pa.us
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

David Rowley <dgrowleyml(at)gmail(dot)com> writes:
> Here's that patchified.

I don't really like this proposal. I think the only reason these
test cases exist at all is to remind us that we aren't very smart
about joins on ctid. In the event that somebody fixes that, these
plans would change --- except that it's really unlikely that
such an optimization could "see through" the DISTINCT you propose
to add. So I think this change basically makes these tests unfit
for any purpose.

I think the reasonable choices are

(1) Remove these test cases completely in all branches. The
argument for this is that we're expending test cycles for pretty
nearly no benefit, and if someone did fix the case then the
tests could be put back with new expected output.

(2) Fix only in v14, to ensure that we don't see another of
these failures.

(3) Do nothing, reasoning that we probably won't see another
such failure in v14's remaining lifespan anyway.

I'm kind of leaning to (1), but (3) is plausible too.
I'm not seeing a lot of point in (2).

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Aditya Gollamudi 2026-08-20 03:01:04 Re: Report bytes and transactions actually sent downtream
Previous Message Zhijie Hou (Fujitsu) 2026-08-20 02:45:47 RE: Proposal: Conflict log history table for Logical Replication