Re: Mixed Locales and Upgrading

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

In response to

Responses

Browse pgsql-general by date

  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