On Sun, Jan 15, 2023 at 04:27:50PM -0500, p...@pfortin.com wrote:
> >3) Again, read the docs multiple times there is a lot to understand.
>
> Agreed. But they could be a little clearer... :)
Agreed the docs are complex, but how can they be clearer?
--
Bruce Momjian https://momjian.u
On Mon, 16 Jan 2023 09:16:27 +1100 Gavan Schneider wrote:
>On 16 Jan 2023, at 8:59, p...@pfortin.com wrote:
>
>> encodings for database "template1" do not match: old "UTF8", new
>> "SQL_ASCII" Failure, exiting
>>
>Suggest the old dB using UTF8 is the better practice, and the new dB should do
>l
p...@pfortin.com writes:
> encodings for database "template1" do not match: old "UTF8", new
> "SQL_ASCII" Failure, exiting
So you need to do the initdb under the same locale setting you
used for the old DB. Looking into its LC_XXX settings should
refresh your memory on what that was.
On 16 Jan 2023, at 8:59, p...@pfortin.com wrote:
> encodings for database "template1" do not match: old "UTF8", new
> "SQL_ASCII" Failure, exiting
>
Suggest the old dB using UTF8 is the better practice, and the new dB should do
likewise
> "template1" is not a DB I've ever messed with; so this wi
On Sun, 2023-01-15 at 16:59 -0500, p...@pfortin.com wrote:
>
>
> encodings for database "template1" do not match: old "UTF8", new
> "SQL_ASCII" Failure, exiting
You almost certainly don't want your new database to use SQL_ASCII.
Init the new cluster with -E UTF8.
On Sun, 15 Jan 2023 16:38:08 -0500 p...@pfortin.com wrote:
>On Sun, 15 Jan 2023 15:59:20 -0500 Tom Lane wrote:
>
>>p...@pfortin.com writes:
>>> On Sun, 15 Jan 2023 14:47:35 -0500 Tom Lane wrote:
I think you misunderstand how this is supposed to work. The -D
argument should point a
On Sun, 15 Jan 2023 15:59:20 -0500 Tom Lane wrote:
>p...@pfortin.com writes:
>> On Sun, 15 Jan 2023 14:47:35 -0500 Tom Lane wrote:
>>> I think you misunderstand how this is supposed to work. The -D
>>> argument should point at an *empty* data directory that has been
>>> freshly initialized with
On Sun, 15 Jan 2023 13:00:58 -0800 Adrian Klaver wrote:
>On 1/15/23 12:41, p...@pfortin.com wrote:
>> On Sun, 15 Jan 2023 12:23:10 -0800 Adrian Klaver wrote:
>>
>>> On 1/15/23 11:27, p...@pfortin.com wrote:
Hi,
I'm fairly new to postgres; but have databases with about 2TB of da
Adrian Klaver writes:
> --clone
I think --clone is probably contraindicated here, given that Pierre
already made a copy of the data. If I understand how that works,
it'll just wind up making another whole copy, but in a time-extended
manner as the tables are modified. Over the long run there wo
On 1/15/23 12:41, p...@pfortin.com wrote:
On Sun, 15 Jan 2023 12:23:10 -0800 Adrian Klaver wrote:
On 1/15/23 11:27, p...@pfortin.com wrote:
Hi,
I'm fairly new to postgres; but have databases with about 2TB of data.
Trying to upgrade from 13.6 to 15.1, pg_upgrade complains with:
[postgres@pf
p...@pfortin.com writes:
> On Sun, 15 Jan 2023 14:47:35 -0500 Tom Lane wrote:
>> I think you misunderstand how this is supposed to work. The -D
>> argument should point at an *empty* data directory that has been
>> freshly initialized with the new version's initdb. pg_upgrade then
>> transfers da
On Sun, 15 Jan 2023 12:23:10 -0800 Adrian Klaver wrote:
>On 1/15/23 11:27, p...@pfortin.com wrote:
>> Hi,
>>
>> I'm fairly new to postgres; but have databases with about 2TB of data.
>>
>> Trying to upgrade from 13.6 to 15.1, pg_upgrade complains with:
>> [postgres@pf ~]$ /usr/bin/pg_upgrade -b
On Sun, 15 Jan 2023 14:47:35 -0500 Tom Lane wrote:
>p...@pfortin.com writes:
>> Trying to upgrade from 13.6 to 15.1, pg_upgrade complains with:
>> [postgres@pf ~]$ /usr/bin/pg_upgrade -b /usr/local/pgsql/bin -B /usr/bin \
>> -d /mnt/db/var/lib/pgsql/data -D /mnt/work/var/lib/pgsql/data \
>> -s
On 1/15/23 11:27, p...@pfortin.com wrote:
Hi,
I'm fairly new to postgres; but have databases with about 2TB of data.
Trying to upgrade from 13.6 to 15.1, pg_upgrade complains with:
[postgres@pf ~]$ /usr/bin/pg_upgrade -b /usr/local/pgsql/bin -B /usr/bin \
-d /mnt/db/var/lib/pgsql/data -D /mn
p...@pfortin.com writes:
> Trying to upgrade from 13.6 to 15.1, pg_upgrade complains with:
> [postgres@pf ~]$ /usr/bin/pg_upgrade -b /usr/local/pgsql/bin -B /usr/bin \
> -d /mnt/db/var/lib/pgsql/data -D /mnt/work/var/lib/pgsql/data \
> -s /tmp -U postgres
> This utility can only upgrade to Pos
Hi,
I'm fairly new to postgres; but have databases with about 2TB of data.
Trying to upgrade from 13.6 to 15.1, pg_upgrade complains with:
[postgres@pf ~]$ /usr/bin/pg_upgrade -b /usr/local/pgsql/bin -B /usr/bin \
-d /mnt/db/var/lib/pgsql/data -D /mnt/work/var/lib/pgsql/data \
-s /tmp -U po
16 matches
Mail list logo