On Tue, Dec 6, 2011 at 7:00 AM, Magnus Hagander 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 be able to pass it
Magnus Hagander wrote:
> On Thu, Nov 3, 2011 at 11:20, Bruce Momjian wrote:
> > Robert Haas wrote:
> >> On Wed, Nov 2, 2011 at 8:31 PM, Bruce Momjian wrote:
> >> > Robert Haas wrote:
> >> >> >> > If nobody objects, I'll go do that. ?Hopefully that should be
> >> >> >> > enough
> >> >> >> > to pu
Magnus Hagander wrote:
> On Thu, Nov 3, 2011 at 11:20, Bruce Momjian wrote:
> > Robert Haas wrote:
> >> On Wed, Nov 2, 2011 at 8:31 PM, Bruce Momjian wrote:
> >> > Robert Haas wrote:
> >> >> >> > If nobody objects, I'll go do that. ?Hopefully that should be
> >> >> >> > enough
> >> >> >> > to pu
On Thu, Nov 3, 2011 at 11:20, Bruce Momjian wrote:
> Robert Haas wrote:
>> On Wed, Nov 2, 2011 at 8:31 PM, Bruce Momjian 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.
>
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
Robert Haas wrote:
> On Wed, Nov 2, 2011 at 8:31 PM, Bruce Momjian 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
On Wed, Nov 2, 2011 at 8:31 PM, Bruce Momjian 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
>> >>
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
On Wed, Nov 2, 2011 at 2:05 PM, Bruce Momjian 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
>> > datab
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 Sat, Oct 29, 2011 at 4:07 PM, Robert Haas wrote:
> On Fri, Oct 28, 2011 at 9:22 PM, Bruce Momjian 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 dep
On Tue, Nov 1, 2011 at 1:53 PM, Bruce Momjian 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 any
>>
On Tue, Nov 1, 2011 at 2:49 PM, Bruce Momjian 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 exi
On Tue, Nov 1, 2011 at 2:36 PM, Bruce Momjian wrote:
> Robert Haas wrote:
>> On Tue, Nov 1, 2011 at 1:53 PM, Bruce Momjian 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.
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,
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 mean
Robert Haas wrote:
> On Tue, Nov 1, 2011 at 1:53 PM, Bruce Momjian 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 whe
Robert Haas wrote:
> On Tue, Nov 1, 2011 at 2:49 PM, Bruce Momjian 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
> >> >> > ski
On Fri, Oct 28, 2011 at 9:22 PM, Bruce Momjian 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 = connectDatabase("postgres",
Robert Haas wrote:
> On Fri, Oct 28, 2011 at 10:16 AM, Bruce Momjian wrote:
> > Robert Haas wrote:
> >> On Fri, Oct 28, 2011 at 10:07 AM, Bruce Momjian wrote:
> >> > OK, then the simplest fix, once you modify pg_dumpall, would be to
> >> > modify pg_upgrade to remove reference to the postgres dat
On Fri, Oct 28, 2011 at 10:18 AM, Bruce Momjian wrote:
> Bruce Momjian wrote:
>> Robert Haas wrote:
>> > On Fri, Oct 28, 2011 at 10:07 AM, Bruce Momjian wrote:
>> > > OK, then the simplest fix, once you modify pg_dumpall, would be to
>> > > modify pg_upgrade to remove reference to the postgres da
On Fri, Oct 28, 2011 at 10:16 AM, Bruce Momjian wrote:
> Robert Haas wrote:
>> On Fri, Oct 28, 2011 at 10:07 AM, Bruce Momjian 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
Bruce Momjian wrote:
> Robert Haas wrote:
> > On Fri, Oct 28, 2011 at 10:07 AM, Bruce Momjian 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
Robert Haas wrote:
> On Fri, Oct 28, 2011 at 10:09 AM, Bruce Momjian 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 th
Robert Haas wrote:
> On Fri, Oct 28, 2011 at 10:07 AM, Bruce Momjian 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_
On Fri, Oct 28, 2011 at 10:09 AM, Bruce Momjian 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 croak
>> (whic
On Fri, Oct 28, 2011 at 10:07 AM, Bruce Momjian 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 maintain a 1-1 mat
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 i
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 ea
On Fri, Oct 28, 2011 at 9:55 AM, Bruce Momjian wrote:
> Robert Haas wrote:
>> On Fri, Oct 28, 2011 at 8:12 AM, Bruce Momjian 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
Robert Haas wrote:
> On Fri, Oct 28, 2011 at 8:12 AM, Bruce Momjian 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.
On 28 October 2011 14:28, Robert Haas wrote:
> On Fri, Oct 28, 2011 at 8:12 AM, Bruce Momjian 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 b
On Fri, Oct 28, 2011 at 8:12 AM, Bruce Momjian 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 pg_dumpall, if
Magnus Hagander wrote:
> On Oct 28, 2011 5:19 AM, "Bruce Momjian" 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.
> > > >
> > >
Magnus Hagander wrote:
> On Oct 28, 2011 5:22 AM, "Tom Lane" wrote:
> >
> > Bruce Momjian 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 c
Tom Lane wrote:
> Bruce Momjian 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 t
On Oct 28, 2011 5:19 AM, "Bruce Momjian" 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 t
On Oct 28, 2011 5:22 AM, "Tom Lane" wrote:
>
> Bruce Momjian 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
Bruce Momjian 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 crap in
Robert Haas wrote:
> On Thu, Oct 27, 2011 at 11:35 PM, Bruce Momjian 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 upt
On Thu, Oct 27, 2011 at 11:35 PM, Bruce Momjian 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 to use tem
Tom Lane wrote:
> Bruce Momjian 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
> >> the
Bruce Momjian 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 won't w
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 mec
* 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 i
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
* 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 instruct
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 be
* 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 possib
Robert Haas wrote:
> On Tue, Oct 4, 2011 at 12:11 PM, Heikki Linnakangas
> 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/
>
On Tue, Oct 4, 2011 at 12:11 PM, Heikki Linnakangas
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/
> Performing Consistency Checks
> -
51 matches
Mail list logo
