Re: pg_upgrade

From: Tomasz Szypowski <tomasz(dot)szypowski(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: pg_upgrade
Date: 2019-03-18 20:55:21
Message-ID: CACmJi2JJhTeecWdrH6DBTHCDW+etvu5CwODwkS_u4sSRedCW9g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Hi Tom,

thanks for the response. After initdb tempate1 has datistemplate as true
and in the pg_upgrade.c is:

/*
* template1 and postgres databases will already exist in the target
* installation, so tell pg_restore to drop and recreate them;
* otherwise we would fail to propagate their database-level
* properties.
*/
create_opts = "--clean --create";

regards
Thomas Szypowski

pon., 18 mar 2019 o 15:33 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> napisał(a):

> Tomasz Szypowski <tomasz(dot)szypowski(at)gmail(dot)com> writes:
> > while using pg_upgrade I receive an error:
>
> > pg_restore: dropping DATABASE template1
> > pg_restore: [archiver (db)] Error while PROCESSING TOC:
> > pg_restore: [archiver (db)] Error from TOC entry 1955; 1262 1 DATABASE
> > template1 postgres
> > pg_restore: [archiver (db)] could not execute query: ERROR: cannot drop
> a
> > template database
> > Command was: DROP DATABASE "template1";
>
> Hmmm ... I could believe this would happen if you've removed the
> is_template marking from template1 in the source installation.
>
> That doesn't seem like a terribly good idea though, so I'm not
> inclined to try to figure a way for pg_dump to work around it.
>
> regards, tom lane
>

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2019-03-18 21:37:41 Re: BUG #15700: PG 10 vs. 11: Large increase in memory usage when selecting BYTEA data (maybe memory leak)
Previous Message Andres Freund 2019-03-18 20:53:07 Re: BUG #15700: PG 10 vs. 11: Large increase in memory usage when selecting BYTEA data (maybe memory leak)