From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com> |
Cc: | Andrus <kobruleht2(at)hot(dot)ee>, pgsql-general <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Query returns no rows in pg_basebackup cluster |
Date: | 2020-05-21 22:47:25 |
Message-ID: | 17696.1590101245@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com> writes:
> On 5/21/20 1:20 PM, Andrus wrote:
>> In windows pg_basebackup was used to create base backup from Linux server.
> Are you referring to two different instances of Postgres on Windows?
No, what it sounds like is the OP tried to physically replicate a
database on another platform with completely different sorting rules.
Which means all his text indexes are corrupt according to the
destination platform's sorting rules, which easily explains the
observed misbehavior (ie, index searches not finding the expected rows).
REINDEX would fix it. But the major point here is you can't just ignore
a collation mismatch, which in turn implies that you can't do physical
replication from Linux to Windows, or vice versa (and most other
cross-platform cases are just as dangerous).
>> Database in Windows is in read-only (recovery) mode so it cannot changed.
Then you might as well just rm -rf it (or whatever the equivalent Windows
incantation is). On Windows, that database is broken and useless.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Adrian Klaver | 2020-05-21 22:57:17 | Re: Query returns no rows in pg_basebackup cluster |
Previous Message | Adrian Klaver | 2020-05-21 22:13:27 | Re: Query returns no rows in pg_basebackup cluster |