Re: BUG #15615: pg_upgrade and vacuum_defer_cleanup_age

From: Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>
To: eshkinkot(at)gmail(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #15615: pg_upgrade and vacuum_defer_cleanup_age
Date: 2020-07-02 09:33:05
Message-ID: a81ba5b530d489c985f3bcb5c424457b5568db17.camel@cybertec.at
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Thu, 2019-01-31 at 16:19 +0000, PG Bug reporting form wrote:
> I use production config for pg_upgrade for new cluster and it has
> vacuum_defer_cleanup_age = 900000
>
> With this setting pg_upgrade cannot freeze pg_catalog in new cluster
> (it do 'vacuumdb --all --freeze') during performing upgrade and upgrade
> fails:
>
> Performing Upgrade
> ------------------
> Analyzing all rows in the new cluster ok
> Freezing all rows on the new cluster ok
> Deleting files from new pg_clog ok
> Copying old pg_clog to new server ok
> Setting next transaction ID and epoch for new cluster ok
> Deleting files from new pg_multixact/offsets ok
> Copying old pg_multixact/offsets to new server ok
> Deleting files from new pg_multixact/members ok
> Copying old pg_multixact/members to new server ok
> Setting next multixact ID and offset for new cluster ok
> Resetting WAL archives ok
>
> connection to database failed: FATAL: database "template1" does not exist
>
>
> could not connect to new postmaster started with the command:
> "/home/test/inst/pg9.6/bin/pg_ctl" -w -l "pg_upgrade_server.log" -D "new/"
> -o "-p 50432 -b -c synchronous_commit=off -c fsync=off -c
> full_page_writes=off -c listen_addresses='' -c unix_socket_permissions=0700
> -c unix_socket_directories='/home/test/tmp/u'" start
> Failure, exiting
>
>
> I did not find any prohibition in the documentation on using production
> config
> with pg_upgrade, may be I am wrong and this is already mentioned in
> documentation.

This has been fixed with
https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=3f5863e15664757393c7a1416181fb58deac37a6

Yours,
Laurenz Albe

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Etsuro Fujita 2020-07-02 11:52:23 Re: BUG #16500: SQL Abend. select multi_key_columns_range_partition_table
Previous Message PG Bug reporting form 2020-07-02 03:16:27 BUG #16523: The wal logs fill the disk and are not cleaned up