From: Tom Lane <tgl@sss.pgh.pa.us>
To: David Rowley <dgrowleyml@gmail.com>
cc: Alexander Lakhin <exclusion@gmail.com>,
        pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: Test tidscan,sql is not immune to autovacuum in v14
In-reply-to: 
 <CAApHDvpmH90A_JAXewP7g=gfrFqO5hOjmHZwC5aZvZJDSSimeg@mail.gmail.com>
References: <f5d1f4c2-6224-4797-be17-c86e77f96c9c@gmail.com>
 <CAApHDvq_4uurbrP30Yc1VJ297+XUT6RAPx9meM8R8g67h5tJdQ@mail.gmail.com>
 <CAApHDvpmH90A_JAXewP7g=gfrFqO5hOjmHZwC5aZvZJDSSimeg@mail.gmail.com>
Comments: In-reply-to David Rowley <dgrowleyml@gmail.com>
	message dated "Thu, 20 Aug 2026 13:07:01 +1200"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <3530858.1787194249.1@sss.pgh.pa.us>
Date: Wed, 19 Aug 2026 22:50:49 -0400
Message-ID: <3530859.1787194249@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/3530859.1787194249%40sss.pgh.pa.us>
Precedence: bulk

David Rowley <dgrowleyml@gmail.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