Re: [External] LIMIT not showing all results - Mailing list pgsql-general

From Matthew Pounsett
Subject Re: [External] LIMIT not showing all results
Date
Msg-id CAAiTEH9c9syRAWdPAEAERYSYiHdUdDRDO6YSxQBBhGK-BqkA+A@mail.gmail.com
Whole thread Raw
In response to Re: [External] LIMIT not showing all results  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [External] LIMIT not showing all results  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-general


On Tue, 5 Mar 2019 at 13:55, Tom Lane <tgl@sss.pgh.pa.us> wrote:

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?)

All of the databases are using en_US.UTF-8, which is (I think) the default these days for most distributions, isn't it?

So yeah.. that would be it.  Thanks for your help.

The rsync migration was because we needed to do a cross-country copy before putting the original DB server on a truck, but we couldn't get pg_basebackup to complete the 22TB sync without dying.  rsync was restartable, so we went that route instead.  Now that the two copies are physically next to each other again, after we do a rebuild of the original server I'll be syncing the data back (this time using pg_basebackup and replication).  I *assume* we shouldn't expect similar collation problems replicating data that way, but it seems prudent to check.  
Should we?

pgsql-general by date:

Previous
From: Casey Deccio
Date:
Subject: Re: [External] LIMIT not showing all results
Next
From: Tom Lane
Date:
Subject: Re: [External] LIMIT not showing all results