On Thu, Nov 3, 2011 at 11:20, Bruce Momjian br...@momjian.us wrote:
Robert Haas wrote:
On Wed, Nov 2, 2011 at 8:31 PM, Bruce Momjian br...@momjian.us wrote:
Robert Haas wrote:
If nobody objects, I'll go do that. ?Hopefully that should be enough
to put this problem to bed more or less
Magnus Hagander wrote:
On Thu, Nov 3, 2011 at 11:20, Bruce Momjian br...@momjian.us wrote:
Robert Haas wrote:
On Wed, Nov 2, 2011 at 8:31 PM, Bruce Momjian br...@momjian.us wrote:
Robert Haas wrote:
If nobody objects, I'll go do that. ?Hopefully that should be
enough
to put
Magnus Hagander wrote:
On Thu, Nov 3, 2011 at 11:20, Bruce Momjian br...@momjian.us wrote:
Robert Haas wrote:
On Wed, Nov 2, 2011 at 8:31 PM, Bruce Momjian br...@momjian.us wrote:
Robert Haas wrote:
If nobody objects, I'll go do that. ?Hopefully that should be
enough
to put
On Tue, Dec 6, 2011 at 7:00 AM, Magnus Hagander mag...@hagander.net wrote:
Seems reasonably clean to me. Not sure what would be unclean about it?
Based on this feedback, I went ahead and committed my previous patch.
This means that if pg_upgrade wants to accept a --maintenance-db
option, it will
Robert Haas wrote:
On Wed, Nov 2, 2011 at 8:31 PM, Bruce Momjian br...@momjian.us wrote:
Robert Haas wrote:
If nobody objects, I'll go do that. ?Hopefully that should be enough
to put this problem to bed more or less permanently.
All right, I've worked up a (rather boring and
Bruce Momjian wrote:
I fixed this a different way. I originally thought I could skip over
the 'postgres' database in the new cluster if it didn't exist in the old
cluster, but we have do things like check it is empty, so that was going
to be awkward.
It turns out there was only one place
On Sat, Oct 29, 2011 at 4:07 PM, Robert Haas robertmh...@gmail.com wrote:
On Fri, Oct 28, 2011 at 9:22 PM, Bruce Momjian br...@momjian.us wrote:
OK, the attached, applied patch removes the pg_upgrade dependency on the
'postgres' database existing in the new cluster. However, vacuumdb,
used by
Robert Haas wrote:
However, we need to rethink the flag to be used for this: pg_dumpall
uses -l, but many of the other utilities already use that for some
other purpose, and it's not exactly mnemonic anyway. ?-d for
database could work, but that's also in use in some places, and
On Wed, Nov 2, 2011 at 2:05 PM, Bruce Momjian br...@momjian.us wrote:
Robert Haas wrote:
However, we need to rethink the flag to be used for this: pg_dumpall
uses -l, but many of the other utilities already use that for some
other purpose, and it's not exactly mnemonic anyway. ?-d for
Robert Haas wrote:
If nobody objects, I'll go do that. ?Hopefully that should be enough
to put this problem to bed more or less permanently.
All right, I've worked up a (rather boring and tedious) patch to do
this, which is attached.
I wonder if we should bother using a flag for
On Wed, Nov 2, 2011 at 8:31 PM, Bruce Momjian br...@momjian.us wrote:
Robert Haas wrote:
If nobody objects, I'll go do that. ?Hopefully that should be enough
to put this problem to bed more or less permanently.
All right, I've worked up a (rather boring and tedious) patch to do
this,
Robert Haas wrote:
On Tue, Nov 1, 2011 at 2:49 PM, Bruce Momjian br...@momjian.us wrote:
Robert Haas wrote:
It turns out there was only one place that expected a 1-1 mapping of
old
and new databases (file transfer), so I just modified that code to
allow
skipping a database
Robert Haas wrote:
On Tue, Nov 1, 2011 at 1:53 PM, Bruce Momjian br...@momjian.us wrote:
Bruce Momjian wrote:
What I would prefer is to have the upgrade succeed, and just ignore
the existence of a postgres database in the new cluster. ?Maybe give
the user a notice and let them decide
Robert Haas wrote:
It turns out there was only one place that expected a 1-1 mapping of old
and new databases (file transfer), so I just modified that code to allow
skipping a database in the new cluster that didn't exist in the old
cluster.
Urp. ?But that means that if someone has
Bruce Momjian wrote:
What I would prefer is to have the upgrade succeed, and just ignore
the existence of a postgres database in the new cluster. Maybe give
the user a notice and let them decide whether they wish to take any
action. I understand that failing is probably less code, but
On Tue, Nov 1, 2011 at 2:36 PM, Bruce Momjian br...@momjian.us wrote:
Robert Haas wrote:
On Tue, Nov 1, 2011 at 1:53 PM, Bruce Momjian br...@momjian.us wrote:
Bruce Momjian wrote:
What I would prefer is to have the upgrade succeed, and just ignore
the existence of a postgres database in
On Tue, Nov 1, 2011 at 2:49 PM, Bruce Momjian br...@momjian.us wrote:
Robert Haas wrote:
It turns out there was only one place that expected a 1-1 mapping of old
and new databases (file transfer), so I just modified that code to allow
skipping a database in the new cluster that didn't
On Tue, Nov 1, 2011 at 1:53 PM, Bruce Momjian br...@momjian.us wrote:
Bruce Momjian wrote:
What I would prefer is to have the upgrade succeed, and just ignore
the existence of a postgres database in the new cluster. Maybe give
the user a notice and let them decide whether they wish to take
On Fri, Oct 28, 2011 at 9:22 PM, Bruce Momjian br...@momjian.us wrote:
OK, the attached, applied patch removes the pg_upgrade dependency on the
'postgres' database existing in the new cluster. However, vacuumdb,
used by pg_upgrade, still has this dependency:
conn =
On Oct 28, 2011 5:22 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Bruce Momjian br...@momjian.us writes:
Stephen Frost wrote:
Yes, they would have removed it because they didn't want it. As I
recall, part of the agreement to create an extra database by default
was
that it could be removed if
On Oct 28, 2011 5:19 AM, Bruce Momjian br...@momjian.us wrote:
Stephen Frost wrote:
Regarding pg_dumpall and pg_restore, I'm pretty sure both of those
can
be configured to connect to other databases instead, including for
globals.
Well, please show me the code, because the C
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
Robert Haas wrote:
that if you're doing something to the database that someone might
object to, you oughtn't be doing it to the postgres database either.
You should create a database just for pg_upgrade's use and install its
crap in
Magnus Hagander wrote:
On Oct 28, 2011 5:22 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Bruce Momjian br...@momjian.us writes:
Stephen Frost wrote:
Yes, they would have removed it because they didn't want it. As I
recall, part of the agreement to create an extra database by default
was
Magnus Hagander wrote:
On Oct 28, 2011 5:19 AM, Bruce Momjian br...@momjian.us wrote:
Stephen Frost wrote:
Regarding pg_dumpall and pg_restore, I'm pretty sure both of those
can
be configured to connect to other databases instead, including for
globals.
Well, please
On Fri, Oct 28, 2011 at 8:12 AM, Bruce Momjian br...@momjian.us wrote:
Yes, that would work, but see my summarization email on this. Using
template1 is not a problem for pg_upgrade, it is the modifications to
pg_dumpall that are an issue.
I just did a bit of testing on this. It appears that
On 28 October 2011 14:28, Robert Haas robertmh...@gmail.com wrote:
On Fri, Oct 28, 2011 at 8:12 AM, Bruce Momjian br...@momjian.us wrote:
Yes, that would work, but see my summarization email on this. Using
template1 is not a problem for pg_upgrade, it is the modifications to
pg_dumpall that
Robert Haas wrote:
On Fri, Oct 28, 2011 at 8:12 AM, Bruce Momjian br...@momjian.us wrote:
Yes, that would work, but see my summarization email on this. ?Using
template1 is not a problem for pg_upgrade, it is the modifications to
pg_dumpall that are an issue.
I just did a bit of testing
On Fri, Oct 28, 2011 at 9:55 AM, Bruce Momjian br...@momjian.us wrote:
Robert Haas wrote:
On Fri, Oct 28, 2011 at 8:12 AM, Bruce Momjian br...@momjian.us wrote:
Yes, that would work, but see my summarization email on this. ?Using
template1 is not a problem for pg_upgrade, it is the
Robert Haas wrote:
But regardless of which database it uses to *generate* the dump, the
dump itself will *always* contain this, right at the very beginning:
\connect postgres
That line is in fact hard-coded as a literal string in pg_dumpall.c.
It seems like the easiest fix here might
Robert Haas wrote:
action. I understand that failing is probably less code, but IMHO one
of the biggest problems with pg_upgrade is that it's too fragile:
there are too many seemingly innocent things that can make it croak
(which isn't good, when you consider that anyone using pg_upgrade is
On Fri, Oct 28, 2011 at 10:07 AM, Bruce Momjian br...@momjian.us wrote:
OK, then the simplest fix, once you modify pg_dumpall, would be to
modify pg_upgrade to remove reference to the postgres database in the
new cluster if it doesn't exist in the old one. That would allow
pg_upgrade to
On Fri, Oct 28, 2011 at 10:09 AM, Bruce Momjian br...@momjian.us wrote:
Robert Haas wrote:
action. I understand that failing is probably less code, but IMHO one
of the biggest problems with pg_upgrade is that it's too fragile:
there are too many seemingly innocent things that can make it
Robert Haas wrote:
On Fri, Oct 28, 2011 at 10:07 AM, Bruce Momjian br...@momjian.us wrote:
OK, then the simplest fix, once you modify pg_dumpall, would be to
modify pg_upgrade to remove reference to the postgres database in the
new cluster if it doesn't exist in the old one. ?That would
Robert Haas wrote:
On Fri, Oct 28, 2011 at 10:09 AM, Bruce Momjian br...@momjian.us wrote:
Robert Haas wrote:
action. ?I understand that failing is probably less code, but IMHO one
of the biggest problems with pg_upgrade is that it's too fragile:
there are too many seemingly innocent
Bruce Momjian wrote:
Robert Haas wrote:
On Fri, Oct 28, 2011 at 10:07 AM, Bruce Momjian br...@momjian.us wrote:
OK, then the simplest fix, once you modify pg_dumpall, would be to
modify pg_upgrade to remove reference to the postgres database in the
new cluster if it doesn't exist in
On Fri, Oct 28, 2011 at 10:16 AM, Bruce Momjian br...@momjian.us wrote:
Robert Haas wrote:
On Fri, Oct 28, 2011 at 10:07 AM, Bruce Momjian br...@momjian.us wrote:
OK, then the simplest fix, once you modify pg_dumpall, would be to
modify pg_upgrade to remove reference to the postgres database
On Fri, Oct 28, 2011 at 10:18 AM, Bruce Momjian br...@momjian.us wrote:
Bruce Momjian wrote:
Robert Haas wrote:
On Fri, Oct 28, 2011 at 10:07 AM, Bruce Momjian br...@momjian.us wrote:
OK, then the simplest fix, once you modify pg_dumpall, would be to
modify pg_upgrade to remove reference
Robert Haas wrote:
On Fri, Oct 28, 2011 at 10:16 AM, Bruce Momjian br...@momjian.us wrote:
Robert Haas wrote:
On Fri, Oct 28, 2011 at 10:07 AM, Bruce Momjian br...@momjian.us wrote:
OK, then the simplest fix, once you modify pg_dumpall, would be to
modify pg_upgrade to remove reference
Robert Haas wrote:
On Tue, Oct 4, 2011 at 12:11 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
pg_upgrade doesn't work if the 'postgres' database has been dropped in the
old cluster:
~/pgsql.master$ bin/pg_upgrade -b ~/pgsql.91stable/bin -B bin/ -d
* Bruce Momjian (br...@momjian.us) wrote:
So, it is going to be confusing to support both databases because there
is the cleanup details I have to document if I use template1.
Presumably there's some other database in the system besides template1
if postgres doesn't exist.. Would it be
Stephen Frost wrote:
-- Start of PGP signed section.
* Bruce Momjian (br...@momjian.us) wrote:
So, it is going to be confusing to support both databases because there
is the cleanup details I have to document if I use template1.
Presumably there's some other database in the system besides
* Bruce Momjian (br...@momjian.us) wrote:
I have not seen enough demand to make this a user-visible configuration.
We can just tell them to create a postgres database. Frankly, they
would have had to _remove_ the postgres database after initdb for it not
to be there, and they are instructed
Stephen Frost wrote:
-- Start of PGP signed section.
* Bruce Momjian (br...@momjian.us) wrote:
I have not seen enough demand to make this a user-visible configuration.
We can just tell them to create a postgres database. Frankly, they
would have had to _remove_ the postgres database after
* Bruce Momjian (br...@momjian.us) wrote:
Well, you would have to remove it _after_ you did the pg_upgrade. Right
now if you do a normal dump/restore upgrade, you also have to re-remove
the postgres database. We don't have any mechanism to drop a database
as part of pg_dumpall's restore if
Stephen Frost wrote:
-- Start of PGP signed section.
* Bruce Momjian (br...@momjian.us) wrote:
Well, you would have to remove it _after_ you did the pg_upgrade. Right
now if you do a normal dump/restore upgrade, you also have to re-remove
the postgres database. We don't have any mechanism
Bruce Momjian br...@momjian.us writes:
Stephen Frost wrote:
Yes, they would have removed it because they didn't want it. As I
recall, part of the agreement to create an extra database by default was
that it could be removed if users didn't want it. Turning around and
then saying but things
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
Stephen Frost wrote:
Yes, they would have removed it because they didn't want it. As I
recall, part of the agreement to create an extra database by default was
that it could be removed if users didn't want it. Turning around and
On Thu, Oct 27, 2011 at 11:35 PM, Bruce Momjian br...@momjian.us wrote:
What about creating a new, single-purpose database in the source
cluster and then removing it again after we're done?
That is not a problem --- I can easily use template1.
Huh?
You just said upthread that you didn't want
Robert Haas wrote:
On Thu, Oct 27, 2011 at 11:35 PM, Bruce Momjian br...@momjian.us wrote:
What about creating a new, single-purpose database in the source
cluster and then removing it again after we're done?
That is not a problem --- I can easily use template1.
Huh?
You just said
Bruce Momjian br...@momjian.us writes:
Robert Haas wrote:
that if you're doing something to the database that someone might
object to, you oughtn't be doing it to the postgres database either.
You should create a database just for pg_upgrade's use and install its
crap in there.
It installs
On Tue, Oct 4, 2011 at 12:11 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
pg_upgrade doesn't work if the 'postgres' database has been dropped in the
old cluster:
~/pgsql.master$ bin/pg_upgrade -b ~/pgsql.91stable/bin -B bin/ -d
~/pgsql.91stable/data -D data-upgraded/
51 matches
Mail list logo
