From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | David Rowley <dgrowleyml(at)gmail(dot)com> |
Cc: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, ganeshmmahesh(at)gmail(dot)com, PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org> |
Subject: | Re: BUG #17068: Incorrect ordering of a particular row. |
Date: | 2021-06-22 14:00:22 |
Message-ID: | 1714546.1624370422@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
David Rowley <dgrowleyml(at)gmail(dot)com> writes:
> On Wed, 23 Jun 2021 at 01:26, Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote:
>> If you change the SELECT list to output alias3::text, there's a
>> different value there:
> Yeah, if I change it to ORDER BY alias3.lastname, nullnamesb.id;
> instead of ORDER BY alias3.*, nullnamesb.id; then the tie break using
> btint4fastcmp() is called more often. It's also getting called with
> the missing 4s which I mentioned upthread.
> See the two outputs. That points me towards something weird going on
> in record_cmp().
I believe Munro's point is that in some rows alias3.* is a NULL composite
value, while in other rows it is a composite containing one NULL, and they
don't sort the same. Presumably the former are from left-join extension
while the latter come from actual table rows having NULL in that column.
(I'd suspected something of the kind, but being caffeine-deprived I'd
first added "alias3.* IS NULL" to the query, which of course fails to
expose the difference. Thanks SQL.)
In short, I see no bug here. It is kind of obscure though.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2021-06-22 14:11:06 | Re: BUG #17064: Parallel VACUUM operations cause the error "global/pg_filenode.map contains incorrect checksum" |
Previous Message | David Rowley | 2021-06-22 13:46:16 | Re: BUG #17068: Incorrect ordering of a particular row. |