Skip site navigation (1) Skip section navigation (2)

Re: [PATCH] pg_upgrade fails when postgres/template1 isn't in default tablespace

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Marti Raudsepp <marti(at)juffo(dot)org>,pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCH] pg_upgrade fails when postgres/template1 isn't in default tablespace
Date: 2015-09-04 00:10:09
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Thu, Sep  3, 2015 at 01:03:30PM +0200, Andres Freund wrote:
> Hi Bruce,
> Are you actually waiting for review in this thread? Or is the CF entry
> more of a reminder?

Oh, I have a commit-fest entry for this?  Well, whoever did that was
doing the right thing so things are not forgotten.  Yeah!  :-)

Anyway, I was going to work on this once I had read my email backlog,
but because of the commit-fest entry, I worked on it today instead.

I have developed the attached patch which fixes the pg_upgrade problem,
and the pg_dumpall problem with postgres and template1 in non-default
tablespaces.  I modified the pg_dumpall patch with the following changes:

*  It is a general pg_dumpall bug, not specific to binary upgrade mode,
so the new code will be used in non-binary upgrade mode too.

* I hard-coded the "connect template1" string, as it is a constant (no
need for %s and fmtId()).

*  You can't mix fprintf() and appendPQExpBuffer() and get the output in
the specified order, i.e. fprintf will come out first.  Now, in your
case, it didn't matter, but it isn't clean either.

*  I wanted the original database connection to be restored right after
the switch.

The new output looks like this:

	\connect postgres
	\connect template1

Based on our previous policy, these are both bugs and cause either
errors or inaccurate restores, so I plan to apply the attached patch to
all back branches.

  Bruce Momjian  <bruce(at)momjian(dot)us>

  + Everyone has their own god. +

Attachment: tablespace.diff
Description: text/x-diff (2.7 KB)

In response to


pgsql-hackers by date

Next:From: Bruce MomjianDate: 2015-09-04 00:11:40
Subject: Re: Freeze avoidance of very large table.
Previous:From: Tatsuo IshiiDate: 2015-09-03 23:28:19
Subject: Re: BRIN INDEX value

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group