From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Don Seiler <don(at)seiler(dot)us> |
Cc: | Postgres General <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Mixed Locales and Upgrading |
Date: | 2020-03-17 14:45:50 |
Message-ID: | 1182.1584456350@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Don Seiler <don(at)seiler(dot)us> writes:
> 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.
> 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)?
Yeah, that's the basic idea.
> What are the ramifications of changing collation like that? Should we
> consider rebuilding indexes ASAP after that?
Text indexes would definitely be at risk here. I'm not really certain
how bad the problem would be. Do you have a feeling for how much of
the data is 100% ASCII? If you could be sure of that for any given
column, you wouldn't have to reindex indexes on that column.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | AC Gomez | 2020-03-17 15:23:19 | Keeping Admin-Owner user but creating new user with effective Admin-Owner access rights? |
Previous Message | Björn Lundin | 2020-03-17 14:39:16 | Re: Order by and timestamp SOLVED |