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

Re: [TESTERS] R: Postgresql 9.0b2 : pg_upgrade not passing username to pgdumpall ?

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: "Cassiano, Marco" <mcassiano(at)manord(dot)com>
Cc: pgsql-admin(at)postgresql(dot)org, pgsql-testers(at)postgresql(dot)org
Subject: Re: [TESTERS] R: Postgresql 9.0b2 : pg_upgrade not passing username to pgdumpall ?
Date: 2010-06-23 20:04:22
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-adminpgsql-testers
Cassiano, Marco wrote:
> Thank you Bruce,
> I applied the patch and  found two things you might want to take in consideration :
> 1) dump.c Line 25 should be : 
> SYSTEMQUOTE, ctx->new.bindir, ctx->old.port, ctx->user, ctx->output_dir);
> And not
> SYSTEMQUOTE, ctx->new.bindir, ctx->old.port, ctx->user, ctx->cwd);
> (sorry, I'm not confident at producing patch files....)

OK, the problem here is that I changed output_dir to cwd since beta2; 
your change is fine for your version of pg_upgrade.

> 2) I then recompiled pg_upgrade and reinstalled it.   Now it goes
> a little bit further but I think there's another point (vacuumdb of
> the new cluster) in which the username is missing.  You might want
>to take a look at this output (/tmp/pg_upgrade.log)

Ah, you are right --- I seem to have missed a bunch of username
designations.  I went through and looked all all the exec calls, and
added the username to each one that supported it;  applied patch

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

  + None of us is going to be here forever. +

Attachment: /rtmp/diff
Description: text/x-diff (6.5 KB)

In response to

pgsql-admin by date

Next:From: Plugge, Joe R.Date: 2010-06-23 21:24:35
Subject: Re: Slony - I question
Previous:From: Tom LaneDate: 2010-06-23 18:34:14
Subject: Re: Unable to start Statistics Collector

pgsql-testers by date

Next:From: Lou PiccianoDate: 2010-07-06 23:37:46
Subject: Location of certs -Windows 7 SSL mode?
Previous:From: Josh BerkusDate: 2010-06-23 18:01:52
Subject: Re: Single-statement INSERT with multiple VALUES clauses behaving strangely...

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