Re: [External] LIMIT not showing all results

Matthew Pounsett <matt(at)conundrum(dot)com> writes:
> 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.

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

Uh, yeah you should. The point here is that Debian and FreeBSD
have different ideas of what en_US.UTF-8 sort order means, so that
an index that's correctly ordered by the lights of one system
is incorrect (corrupt) according to the other.

If you're planninng to install (the same version of) FreeBSD on
the original server hardware, then rsync'ing back from the new
system should be fine. But Debian<->FreeBSD is gonna be trouble
in either direction.

We generally don't recommend physical database transfers across
OS boundaries, and this is the main reason why.

regards, tom lane