From: | Don Seiler <don(at)seiler(dot)us> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Postgres General <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Mixed Locales and Upgrading |
Date: | 2020-03-17 14:35:51 |
Message-ID: | CAHJZqBDAqGbgAHxVQ1rG1QmKPpkqU_W8yi82EdqA-o_0WgaLYw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Tue, Mar 17, 2020 at 8:56 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Yikes. Well, if there aren't obvious operational problems, it might be
> that the data is actually UTF8-clean, or almost entirely so. Maybe you
> could look at the problem as being one of validation. In that case,
> it'd be possible to consider not taking the production DB down, but just
> doing a pg_dump from it and seeing if you can restore somewhere else.
> If not, fix the broken data; repeat till clean. After that you could
> do pg_upgrade with a clear conscience. I think you'll still end up
> manually fixing the inconsistent datcollate/datctype settings though.
>
For this test, would we restore into an en_US.UTF-8/UTF8 database? Then,
assuming no errors (or fixing any errors until clean), we change the
datcollate/datctype settings in prod and proceed with pg_upgrade (obviously
after testing all of that heavily)?
What are the ramifications of changing collation like that? Should we
consider rebuilding indexes ASAP after that?
Don.
--
Don Seiler
www.seiler.us
From | Date | Subject | |
---|---|---|---|
Next Message | Björn Lundin | 2020-03-17 14:39:16 | Re: Order by and timestamp SOLVED |
Previous Message | Tom Lane | 2020-03-17 14:05:01 | Re: Order by and timestamp SOLVED |