Re: [External] LIMIT not showing all results

From: Matthew Pounsett <matt(at)conundrum(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
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 23:03:08
Message-ID: CAAiTEH9c9syRAWdPAEAERYSYiHdUdDRDO6YSxQBBhGK-BqkA+A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Tue, 5 Mar 2019 at 13:55, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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?

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2019-03-05 23:09:34 Re: [External] LIMIT not showing all results
Previous Message Casey Deccio 2019-03-05 21:53:44 Re: [External] LIMIT not showing all results