Re: Problems with pg_upgrade after change of unix user running db.

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Benedikt Grundmann <bgrundmann(at)janestreet(dot)com>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: Problems with pg_upgrade after change of unix user running db.
Date: 2015-11-25 14:43:51
Message-ID: 20151125144351.GB17361@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Wed, Nov 25, 2015 at 08:04:49AM +0000, Benedikt Grundmann wrote:
> You can see the 9.5 requirements in the pg_upgrade function
> check_is_install_user().  You might as well just honor what that
> requires as you will eventually be moving to 9.5.
>
>
> Thanks I'll try this in one of the next days.  Sorry for the radio silence in
> the last 2 days.  We have been quite busy at work.  I don't think I understand

Sure, no problem. I would have liked to reply to this sooner too, but
had to do some research.

> yet why this restriction exists (Neither the old nor the new).  Is there some
> doc somewhere that explains what's going on?  I tried to find something in the
> otherwise excellent postgres docs but failed.

The comments at the top of pg_upgrade.c do explain this:

* To simplify the upgrade process, we force certain system values to be
* identical between old and new clusters:
*
* We control all assignments of pg_class.oid (and relfilenode) so toast
* oids are the same between old and new clusters. This is important
* because toast oids are stored as toast pointers in user tables.
*
* While pg_class.oid and pg_class.relfilenode are initially the same
* in a cluster, they can diverge due to CLUSTER, REINDEX, or VACUUM
* FULL. In the new cluster, pg_class.oid and pg_class.relfilenode will
* be the same and will match the old pg_class.oid value. Because of
* this, old/new pg_class.relfilenode values will not match if CLUSTER,
* REINDEX, or VACUUM FULL have been performed in the old cluster.
*
* We control all assignments of pg_type.oid because these oids are stored
* in user composite type values.
*
* We control all assignments of pg_enum.oid because these oids are stored
* in user tables as enum values.
*
* We control all assignments of pg_authid.oid because these oids are stored <---
* in pg_largeobject_metadata. <---

I never expected users to care, but based on what you did, you obviously
did need to care. The good news is that the system generated an error
message that helped diagnose the problem, and the 9.5 error message is
much clearer.

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

+ As you are, so once was I. As I am, so you will be. +
+ Roman grave inscription +

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Adrian Klaver 2015-11-25 14:47:52 Re: Unexpected behaviour of 'DEFERRABLE INITIALLY DEFERRED'
Previous Message NTPT 2015-11-25 13:56:29 RE: [GENERAL] Query failed: ERROR: character with byte sequence 0xc2 0x96 in encoding "UTF8" has no equivalent in encoding "WIN1250"