From: Tom Lane <tgl@sss.pgh.pa.us>
To: David Rowley <dgrowleyml@gmail.com>
cc: pgsql-committers@lists.postgresql.org
Subject: Re: pgsql: Fix test case from b0c5b215d.
In-reply-to: <1539986.1714441226@sss.pgh.pa.us>
References: <E1s1bHM-000hcK-87@gemulon.postgresql.org>
 <CAApHDvo8pMk5WWFAqwGzuQ-Xh+957W61io_OsCP0oUzqCCODTg@mail.gmail.com>
 <1539986.1714441226@sss.pgh.pa.us>
Comments: In-reply-to Tom Lane <tgl@sss.pgh.pa.us>
	message dated "Mon, 29 Apr 2024 21:40:26 -0400"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1544492.1714443268.1@sss.pgh.pa.us>
Date: Mon, 29 Apr 2024 22:14:28 -0400
Message-ID: <1544493.1714443268@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/1544493.1714443268%40sss.pgh.pa.us>
Precedence: bulk

I wrote:
> I committed that suggestion, but I'm not sure it's enough to fix it,
> because if I do
> 	LANG=cs_CZ.utf8 make check
> then I still get variant output order.  I tried about six different
> spellings of the query without improving matters, so I'm totally
> baffled.  Have we managed to break COLLATE "C"?  (With one eye on
> Jeff Davis' recent stuff, I could believe that, except I'd have
> expected it to show up in other regression tests already.)

Yeah, the affected buildfarm members seem still not happy.

In simple testing such as
	select * from foo order by f1 collate "C";
the behavior seems as expected.  I also confirmed that I see the test
misbehavior locally with or without ICU.  So I kind of think that this
is not a failure in the sorting code per se.  My current idea is that
in a more complicated query such as the new test_pg_dump query, we are
somehow losing the COLLATE "C" specification --- it's there in the
Sort node according to EXPLAIN VERBOSE, but it sure doesn't seem to be
having any effect.

I'm too tired to look any closer tonight, though.

			regards, tom lane