Re: [External] LIMIT not showing all results

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Matthew Pounsett <matt(at)conundrum(dot)com>
Cc: Andreas Kretschmer <andreas(at)a-kretschmer(dot)de>, pgsql-general(at)lists(dot)postgresql(dot)org
Subject: Re: [External] LIMIT not showing all results
Date: 2019-03-05 18:55:18
Message-ID: 16683.1551812118@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Matthew Pounsett <matt(at)conundrum(dot)com> writes:
> On Tue, 5 Mar 2019 at 12:54, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Given that (a) this was triggered by a server migration and (b)
>> the leading column of the index looks like it's probably varchar,
>> I'm suspicious that the new server has different collation behavior.

> The migration in question was an rsync from a Debian 9 box
> running 9.4.19-0+deb8u1 to a FreeBSD 11 box running 9.4.20.

Yeah, that would fit the theory :-(. Debian would be using glibc
and FreeBSD would not be. If you were using C collation in the
database, you'd be all right because that's standardized, but I'll
bet you were using something else. What does psql \l show for the
"collate" setting of this database? (Or, if by chance you had an
explicit COLLATE setting on the column in question, what's that?)

In any case, you should be reindexing any indexes on textual columns
that were not using "C" collation; none of them can be trusted.
The system catalogs should be OK.

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Rory Campbell-Lange 2019-03-05 19:49:45 Server upgrade advice
Previous Message Andreas Kretschmer 2019-03-05 18:44:05 Re: LIMIT not showing all results