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

2016-10-04 Thread Benedikt Grundmann
On 4 October 2016 at 09:28, Benedikt Grundmann wrote: > > > On 4 October 2016 at 08:17, Benedikt Grundmann > wrote: > >> >> On 3 October 2016 at 21:01, Tom Lane wrote: >> >>> Benedikt Grundmann

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

2016-10-04 Thread Benedikt Grundmann
On 4 October 2016 at 08:17, Benedikt Grundmann wrote: > > On 3 October 2016 at 21:01, Tom Lane wrote: > >> Benedikt Grundmann writes: >> > proddb_testing=# SELECT >> >

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

2016-10-04 Thread Benedikt Grundmann
On 3 October 2016 at 21:01, Tom Lane wrote: > Benedikt Grundmann writes: > > proddb_testing=# SELECT > > conname,convalidated,conislocal,coninhcount,connoinherit > > proddb_testing-# FROM pg_constraint WHERE conrelid = > >

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

2016-10-03 Thread Tom Lane
Benedikt Grundmann writes: > proddb_testing=# SELECT > conname,convalidated,conislocal,coninhcount,connoinherit > proddb_testing-# FROM pg_constraint WHERE conrelid = > 'js_activity_20110101'::regclass; >conname | convalidated |

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

2016-10-03 Thread Benedikt Grundmann
On 3 October 2016 at 15:54, Tom Lane wrote: > Benedikt Grundmann writes: > > And it looks like now I'm back to the error that stopped me last time: > > pg_restore: [archiver (db)] Error from TOC entry 8425; 2606 416548282 > CHECK > > CONSTRAINT

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

2016-10-03 Thread Tom Lane
Benedikt Grundmann writes: > And it looks like now I'm back to the error that stopped me last time: > pg_restore: [archiver (db)] Error from TOC entry 8425; 2606 416548282 CHECK > CONSTRAINT seqno_not_null postgres_prod > pg_restore: [archiver (db)] could not execute

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

2016-10-03 Thread Benedikt Grundmann
On 3 October 2016 at 15:30, Tom Lane wrote: > Benedikt Grundmann writes: > > On 3 October 2016 at 14:12, Tom Lane wrote: > >> You're going to need to manually drop that operator from the source > >> database, as "=>" isn't a

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

2016-10-03 Thread Tom Lane
Benedikt Grundmann writes: > On 3 October 2016 at 14:12, Tom Lane wrote: >> You're going to need to manually drop that operator from the source >> database, as "=>" isn't a legal operator name anymore. This appears >> to be left over from a pre-9.0

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

2016-10-03 Thread Benedikt Grundmann
On 3 October 2016 at 14:12, Tom Lane wrote: > Benedikt Grundmann writes: > > I just tried this again. This time from 9.2.17 to 9.5.4 and pg_upgrade > > chokes with this: > > > > [root@igm-dbc-001 upgrade-logs]# tail pg_upgrade_dump_16416.log > >

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

2016-10-03 Thread Tom Lane
Benedikt Grundmann writes: > I just tried this again. This time from 9.2.17 to 9.5.4 and pg_upgrade > chokes with this: > > [root@igm-dbc-001 upgrade-logs]# tail pg_upgrade_dump_16416.log > pg_restore: [archiver (db)] could not execute query: ERROR: syntax error > at

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

2016-10-03 Thread Benedikt Grundmann
On 30 November 2015 at 17:01, Bruce Momjian wrote: > On Mon, Nov 30, 2015 at 04:51:15PM +, Benedikt Grundmann wrote: > > Are you able to compile from 9.4 git head and test that? It seems > > dumping inheriting constraints from parents has not worked properly > for

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

2015-11-30 Thread Bruce Momjian
On Mon, Nov 30, 2015 at 04:51:15PM +, Benedikt Grundmann wrote: > Are you able to compile from 9.4 git head and test that?  It seems > dumping inheriting constraints from parents has not worked properly for > some time. > > > Do I need to get the latest/head 9.2 or the

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

2015-11-30 Thread Bruce Momjian
On Mon, Nov 30, 2015 at 08:08:50AM +, Benedikt Grundmann wrote: > > > On Sat, Nov 28, 2015 at 2:39 AM, Adrian Klaver > wrote: > > On 11/27/2015 06:07 PM, Tom Lane wrote: > > Adrian Klaver writes: > >> On 11/27/2015 08:15

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

2015-11-30 Thread Benedikt Grundmann
On Mon, Nov 30, 2015 at 4:29 PM, Bruce Momjian wrote: > On Mon, Nov 30, 2015 at 08:08:50AM +, Benedikt Grundmann wrote: > > > > > > On Sat, Nov 28, 2015 at 2:39 AM, Adrian Klaver < > adrian.kla...@aklaver.com> > > wrote: > > > > On 11/27/2015 06:07 PM, Tom Lane wrote: >

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

2015-11-30 Thread Benedikt Grundmann
On Sat, Nov 28, 2015 at 2:39 AM, Adrian Klaver wrote: > On 11/27/2015 06:07 PM, Tom Lane wrote: > > Adrian Klaver writes: > >> On 11/27/2015 08:15 AM, Bruce Momjian wrote: > >>> My guess is you are sharing the constraint name

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

2015-11-27 Thread Adrian Klaver
On 11/27/2015 08:05 AM, Benedikt Grundmann wrote: On Fri, Nov 27, 2015 at 4:04 PM, Bruce Momjian > wrote: On Fri, Nov 27, 2015 at 09:38:54AM +, Benedikt Grundmann wrote: > That worked (I also swapped the password columns so that I don't

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

2015-11-27 Thread Benedikt Grundmann
On Fri, Nov 27, 2015 at 4:04 PM, Bruce Momjian wrote: > On Fri, Nov 27, 2015 at 09:38:54AM +, Benedikt Grundmann wrote: > > That worked (I also swapped the password columns so that I don't have to > change > > pgpass entries). But I then ran into a different problem a

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

2015-11-27 Thread Bruce Momjian
On Fri, Nov 27, 2015 at 04:05:46PM +, Benedikt Grundmann wrote: > > [as-proddb@nyc-dbc-001 upgrade-logs]$ tail pg_upgrade_dump_16416.log > > pg_restore: creating CHECK CONSTRAINT seqno_not_null > > pg_restore: creating CHECK CONSTRAINT seqno_not_null > > pg_restore: [archiver

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

2015-11-27 Thread Bruce Momjian
On Fri, Nov 27, 2015 at 09:38:54AM +, Benedikt Grundmann wrote: > That worked (I also swapped the password columns so that I don't have to > change > pgpass entries).  But I then ran into a different problem a little later on.  > I > thought I quickly mention it here in case somebody can

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

2015-11-27 Thread Tom Lane
Adrian Klaver writes: > On 11/27/2015 08:15 AM, Bruce Momjian wrote: >> My guess is you are sharing the constraint name "seqno_not_null" with >> multiple tables. I think you are going to have to dig into the system >> tables to see where that is referenced and fix it.

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

2015-11-27 Thread Adrian Klaver
On 11/27/2015 06:07 PM, Tom Lane wrote: > Adrian Klaver writes: >> On 11/27/2015 08:15 AM, Bruce Momjian wrote: >>> My guess is you are sharing the constraint name "seqno_not_null" with >>> multiple tables. I think you are going to have to dig into the system >>>

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

2015-11-27 Thread Adrian Klaver
On 11/27/2015 08:15 AM, Bruce Momjian wrote: > On Fri, Nov 27, 2015 at 04:05:46PM +, Benedikt Grundmann wrote: >> > [as-proddb@nyc-dbc-001 upgrade-logs]$ tail pg_upgrade_dump_16416.log >> > pg_restore: creating CHECK CONSTRAINT seqno_not_null >> > pg_restore: creating CHECK

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

2015-11-27 Thread Benedikt Grundmann
On Wed, Nov 25, 2015 at 2:43 PM, Bruce Momjian wrote: > On Wed, Nov 25, 2015 at 08:04:49AM +, 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 > >

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

2015-11-25 Thread Benedikt Grundmann
On Tue, Nov 24, 2015 at 8:04 PM, Bruce Momjian wrote: > On Mon, Nov 23, 2015 at 11:12:25AM +, Benedikt Grundmann wrote: > > I got this error trying to upgrade one of our database clusters (happily > in > > testing) from 9.2 to 9.4: > > > > Old and new cluster install users

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

2015-11-25 Thread Bruce Momjian
On Wed, Nov 25, 2015 at 08:04:49AM +, 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

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

2015-11-24 Thread Bruce Momjian
On Mon, Nov 23, 2015 at 11:12:25AM +, Benedikt Grundmann wrote: > I got this error trying to upgrade one of our database clusters (happily in > testing) from 9.2 to 9.4: > > Old and new cluster install users have different values for pg_authid.oid > > Important background here is that we

[GENERAL] Problems with pg_upgrade after change of unix user running db.

2015-11-23 Thread Benedikt Grundmann
I got this error trying to upgrade one of our database clusters (happily in testing) from 9.2 to 9.4: Old and new cluster install users have different values for pg_authid.oid Important background here is that we used to run the database as the postgres unix user, but recently we had changed it

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

2015-11-23 Thread Jim Nasby
On 11/23/15 5:12 AM, Benedikt Grundmann wrote: So I would love to know what the recommended way to go forward is. Ideally it avoids using the old postgres unix and database user (we want to completely get rid of it eventually, but if I have to do some additional one off work this time to get