Re: BUG #13179: pg_upgrade failure.

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Corey Huinker <corey(dot)huinker(at)gmail(dot)com>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #13179: pg_upgrade failure.
Date: 2015-05-09 19:41:08
Message-ID: 20150509194108.GH30684@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Wed, May 6, 2015 at 02:58:01PM -0400, Corey Huinker wrote:
> Good to know about set search_path from current!
>
> However, this shows an issue: a database which appears functional to the
> customer will fail to upgrade, and the only error message in the log file
> complains of an object that does not exist, despite the same log file showing
> that it does. Customers, already frustrated, might find that error confusing,
> and might find the eventual explanation unsatisfying. After all, the database
> worked for them, and they never do the thing that will make their code break.
>
> The desired behavior would be an upgraded database that continues to have the
> problem of a function that will mal-function when a user changes their search
> path.
>
> Failing that, an improved error message would help.
>
> Alternately, a warning message at function creation time when
> ambiguously-pathed objects are referenced.

FYI, pg_upgrade is blindly calling pg_dump/pg_restore and erroring out
if there is any failure, so any fix would have to be done at that level.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ Everyone has their own god. +

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Thomas Munro 2015-05-09 21:41:02 Re: Re: BUG #12990: Missing pg_multixact/members files (appears to have wrapped, then truncated)
Previous Message Bruce Momjian 2015-05-09 18:13:09 Re: psqlodbc: HEAD fails to build with recent clang