FYI, I consider all the issues below to be addressed (we did all but
#4), and pg_migrator will take advantage of these new facilities for 8.5.
---
Bruce Momjian wrote:
> pg_migrator has become more popular recently, so it se
Bruce Momjian wrote:
> Bruce Momjian wrote:
> > 2) Right now pg_migrator renames old tablespaces to .old, which fails
> > if the tablespaces are on mount points. I have already received a
> > report of such a failure. $PGDATA also has that issue, but that
> > renaming has to be done by the user
Bruce Momjian wrote:
> 2) Right now pg_migrator renames old tablespaces to .old, which fails
> if the tablespaces are on mount points. I have already received a
> report of such a failure. $PGDATA also has that issue, but that
> renaming has to be done by the user before pg_migrator is run, and
Alvaro Herrera wrote:
> Bruce Momjian escribi?:
>
> > > Oh, interesting about pg_dump. Let's just go with --analyze-only.
> > > --only-analyze is feeling odd to me too.
> >
> > Done, attached and applied.
>
>
> Why -o and not, say, -Z? I imagine you picked -o for "only" but it
> seems strange
Bruce Momjian escribió:
> > Oh, interesting about pg_dump. Let's just go with --analyze-only.
> > --only-analyze is feeling odd to me too.
>
> Done, attached and applied.
Why -o and not, say, -Z? I imagine you picked -o for "only" but it
seems strange.
--
Alvaro Herrera
> Tom Lane wrote:
> > Peter Eisentraut writes:
> > > On mn, 2010-01-04 at 13:07 -0500, Bruce Momjian wrote:
> > >> Yea, I am not excited about having vacuumdb do only analyze, but it
> > >> seems the most minimal solution. I spelled it --only-analyze and just
> > >> posted the reason and patch.
>
Tom Lane wrote:
> Peter Eisentraut writes:
> > On m??n, 2010-01-04 at 13:07 -0500, Bruce Momjian wrote:
> >> Yea, I am not excited about having vacuumdb do only analyze, but it
> >> seems the most minimal solution. I spelled it --only-analyze and just
> >> posted the reason and patch.
>
> > I ca
Peter Eisentraut writes:
> On mån, 2010-01-04 at 13:07 -0500, Bruce Momjian wrote:
>> Yea, I am not excited about having vacuumdb do only analyze, but it
>> seems the most minimal solution. I spelled it --only-analyze and just
>> posted the reason and patch.
> I can't find the patch and the rea
On mån, 2010-01-04 at 13:07 -0500, Bruce Momjian wrote:
> Yea, I am not excited about having vacuumdb do only analyze, but it
> seems the most minimal solution. I spelled it --only-analyze and just
> posted the reason and patch.
I can't find the patch and the reason, but note that we already have
Bruce Momjian wrote:
> 2) Right now pg_migrator renames old tablespaces to .old, which fails
> if the tablespaces are on mount points. I have already received a
> report of such a failure. $PGDATA also has that issue, but that
> renaming has to be done by the user before pg_migrator is run, and
Zdenek Kotala wrote:
> Dne 4.01.10 19:28, Alvaro Herrera napsal(a):
> > Bruce Momjian escribi?:
> >
> >> I considered that but realize that pg_migrator has to read
> >> pg_controldata in both the old and new servers, meaning it would need
> >> access to both C structures, and considering they bot
Dne 4.01.10 19:28, Alvaro Herrera napsal(a):
Bruce Momjian escribió:
I considered that but realize that pg_migrator has to read
pg_controldata in both the old and new servers, meaning it would need
access to both C structures, and considering they both have the same
structure names, that would
On Jan 6, 2010, at 1:52 AM, decibel wrote:
> On Dec 30, 2009, at 9:50 PM, Bruce Momjian wrote:
>> 3) There is no easy way to analyze all databases. vacuumdb --analyze
>> does analyze _and_ vacuum, which for an 8.4 to 8.5 migration does an
>> unnecessary vacuum. Right now I recommend ANALYZE in e
On Dec 30, 2009, at 9:50 PM, Bruce Momjian wrote:
> 3) There is no easy way to analyze all databases. vacuumdb --analyze
> does analyze _and_ vacuum, which for an 8.4 to 8.5 migration does an
> unnecessary vacuum. Right now I recommend ANALYZE in every database,
> but it would be nice if there w
Bruce Momjian wrote:
> Alvaro Herrera wrote:
> > > 3) There is no easy way to analyze all databases. vacuumdb --analyze
> > > does analyze _and_ vacuum, which for an 8.4 to 8.5 migration does an
> > > unnecessary vacuum. Right now I recommend ANALYZE in every database,
> > > but it would be nice
Bruce Momjian wrote:
> Bruce Momjian wrote:
> > pg_migrator has become more popular recently, so it seems time to look
> > at some enhancements that would improve pg_migrator. None of these are
> > required, but rather changes that would be nice to have:
> >
> > 1) Right now pg_migrator preserve
Alvaro Herrera wrote:
> Bruce Momjian wrote:
> > pg_migrator has become more popular recently, so it seems time to look
> > at some enhancements that would improve pg_migrator. None of these are
> > required, but rather changes that would be nice to have:
> >
> > 1) Right now pg_migrator preserv
Tom Lane wrote:
> Robert Haas writes:
> > On Tue, Jan 5, 2010 at 11:06 AM, Alvaro Herrera
> > wrote:
> >> Tom Lane wrote:
> >>> Good point. ?Using catversion for the purpose seems a bit ugly but
> >>> I have no better ideas.
> >>
> >> I thought we had rejected the idea of being able to migrate b
Robert Haas writes:
> On Tue, Jan 5, 2010 at 11:06 AM, Alvaro Herrera
> wrote:
>> Tom Lane wrote:
>>> Good point. Using catversion for the purpose seems a bit ugly but
>>> I have no better ideas.
>>
>> I thought we had rejected the idea of being able to migrate between
>> alphas. Is migrating
On Tue, Jan 5, 2010 at 11:06 AM, Alvaro Herrera
wrote:
> Tom Lane wrote:
>> Bruce Momjian writes:
>> > I liked the idea, but I listed it as item #2 and no one else said they
>> > liked it. The only complexity I can see with the idea is that doing an
>> > upgrade from one alpha to another would h
Tom Lane wrote:
> Bruce Momjian writes:
> > I liked the idea, but I listed it as item #2 and no one else said they
> > liked it. The only complexity I can see with the idea is that doing an
> > upgrade from one alpha to another would have the same major version
> > number and would therefore not
Bruce Momjian writes:
> I liked the idea, but I listed it as item #2 and no one else said they
> liked it. The only complexity I can see with the idea is that doing an
> upgrade from one alpha to another would have the same major version
> number and would therefore not be possible, so maybe we h
Tom Lane wrote:
> Bruce Momjian writes:
> > Alvaro Herrera wrote:
> >> I thought it was impossible to use bare mountpoints as tablespaces due
> >> to ownership problems ... Is that not the case? -1 for special hacks
> >> that work around bogus setups, if that means intrusive changes to the
> >> c
Bruce Momjian writes:
> Well, when you restore the old dump's schema into the new server, the
> tablespace directory path will be the same, so we had better not have
> any directory there.
If we implicitly added "/8.5" etc at the end of the specified tablespace
path, the problems go away.
Bruce Momjian writes:
> Alvaro Herrera wrote:
>> I thought it was impossible to use bare mountpoints as tablespaces due
>> to ownership problems ... Is that not the case? -1 for special hacks
>> that work around bogus setups, if that means intrusive changes to the
>> core code.
> I talked to the
Bruce Momjian wrote:
> pg_migrator has become more popular recently, so it seems time to look
> at some enhancements that would improve pg_migrator. None of these are
> required, but rather changes that would be nice to have:
>
> 1) Right now pg_migrator preserves relfilenodes for TOAST files be
Bruce Momjian wrote:
> pg_migrator has become more popular recently, so it seems time to look
> at some enhancements that would improve pg_migrator. None of these are
> required, but rather changes that would be nice to have:
>
> 1) Right now pg_migrator preserves relfilenodes for TOAST files be
Robert Haas wrote:
> >> But can't we just call a special function first before running the
> >> CREATE TABLESPACE, like:
> >>
> >> pg_tablespace_dont_really_create_this_tablespace_because_we_are_in_pg_migrator()?
> >>
> >> Sorta like what you did to preserve ENUM OIDs, etc.?
> >
> > Well, the probl
On Mon, Jan 4, 2010 at 4:53 PM, Bruce Momjian wrote:
> Robert Haas wrote:
>> >> >> What doesn't work if we just don't rename the tablespace at all? ?And
>> >> >> can't we put some smarts into the backend to handle that thing?
>> >> >
>> >> > Well, when you restore the old dump's schema into the ne
Robert Haas wrote:
> >> >> What doesn't work if we just don't rename the tablespace at all? ?And
> >> >> can't we put some smarts into the backend to handle that thing?
> >> >
> >> > Well, when you restore the old dump's schema into the new server, the
> >> > tablespace directory path will be the s
On Mon, Jan 4, 2010 at 3:33 PM, Bruce Momjian wrote:
> Robert Haas wrote:
>> On Mon, Jan 4, 2010 at 2:52 PM, Bruce Momjian wrote:
>> > Robert Haas wrote:
>> >> On Mon, Jan 4, 2010 at 2:11 PM, Bruce Momjian wrote:
>> >> > Alvaro Herrera wrote:
>> >> >> > 2) ?Right now pg_migrator renames old tabl
Bruce Momjian wrote:
> Alvaro Herrera wrote:
> > > 2) Right now pg_migrator renames old tablespaces to .old, which fails
> > > if the tablespaces are on mount points. I have already received a
> > > report of such a failure.
> >
> > I thought it was impossible to use bare mountpoints as tablespa
Robert Haas wrote:
> On Mon, Jan 4, 2010 at 2:52 PM, Bruce Momjian wrote:
> > Robert Haas wrote:
> >> On Mon, Jan 4, 2010 at 2:11 PM, Bruce Momjian wrote:
> >> > Alvaro Herrera wrote:
> >> >> > 2) ?Right now pg_migrator renames old tablespaces to .old, which fails
> >> >> > if the tablespaces are
On Mon, Jan 4, 2010 at 2:52 PM, Bruce Momjian wrote:
> Robert Haas wrote:
>> On Mon, Jan 4, 2010 at 2:11 PM, Bruce Momjian wrote:
>> > Alvaro Herrera wrote:
>> >> > 2) ?Right now pg_migrator renames old tablespaces to .old, which fails
>> >> > if the tablespaces are on mount points. ?I have alrea
Robert Haas wrote:
> On Mon, Jan 4, 2010 at 2:11 PM, Bruce Momjian wrote:
> > Alvaro Herrera wrote:
> >> > 2) ?Right now pg_migrator renames old tablespaces to .old, which fails
> >> > if the tablespaces are on mount points. ?I have already received a
> >> > report of such a failure.
> >>
> >> I t
Tom Lane wrote:
> Bruce Momjian writes:
> > I was just really asking if disallowing pg_resetxlog -n on a live server
> > is planned behavior or an oversight. I can see the logic that it should
> > be disallowed but I am just looking for confirmation from someone and I
> > can then drop the issue.
On Mon, Jan 4, 2010 at 2:11 PM, Bruce Momjian wrote:
> Alvaro Herrera wrote:
>> > 2) Right now pg_migrator renames old tablespaces to .old, which fails
>> > if the tablespaces are on mount points. I have already received a
>> > report of such a failure.
>>
>> I thought it was impossible to use b
Bruce Momjian writes:
> I was just really asking if disallowing pg_resetxlog -n on a live server
> is planned behavior or an oversight. I can see the logic that it should
> be disallowed but I am just looking for confirmation from someone and I
> can then drop the issue.
Well, it's not only a ma
Alvaro Herrera wrote:
> > 2) Right now pg_migrator renames old tablespaces to .old, which fails
> > if the tablespaces are on mount points. I have already received a
> > report of such a failure.
>
> I thought it was impossible to use bare mountpoints as tablespaces due
> to ownership problems .
Alvaro Herrera wrote:
> Bruce Momjian escribi?:
>
> > I considered that but realize that pg_migrator has to read
> > pg_controldata in both the old and new servers, meaning it would need
> > access to both C structures, and considering they both have the same
> > structure names, that would requir
Alvaro Herrera wrote:
> Bruce Momjian wrote:
> > pg_migrator has become more popular recently, so it seems time to look
> > at some enhancements that would improve pg_migrator. None of these are
> > required, but rather changes that would be nice to have:
> >
> > 1) Right now pg_migrator preserv
Bruce Momjian escribió:
> I considered that but realize that pg_migrator has to read
> pg_controldata in both the old and new servers, meaning it would need
> access to both C structures, and considering they both have the same
> structure names, that would require some odd C tricks. Add to that
Robert Haas wrote:
> >> 4) ?I have implemented the ability to run pg_migrator --check on a live
> >> old server. ?However, pg_migrator uses information from controldata to
> >> check things, and it also needs xid information that is only available
> >> via pg_resetxlog -n(no update) to perform the
Robert Haas wrote:
> >> 3) ?There is no easy way to analyze all databases. ?vacuumdb --analyze
> >> does analyze _and_ vacuum, which for an 8.4 to 8.5 migration does an
> >> unnecessary vacuum. ?Right now I recommend ANALYZE in every database,
> >> but it would be nice if there were a single comman
Alvaro Herrera wrote:
> > 3) There is no easy way to analyze all databases. vacuumdb --analyze
> > does analyze _and_ vacuum, which for an 8.4 to 8.5 migration does an
> > unnecessary vacuum. Right now I recommend ANALYZE in every database,
> > but it would be nice if there were a single command
Alvaro Herrera writes:
> Getting rid of the need for placeholders is a good idea. +1 on getting
> TOAST tables created with the correct relfilenode from the start. I
> don't know that preserving any other relfilenode is useful; however if
> it means you no longer have to rename the files underly
Bruce Momjian wrote:
> pg_migrator has become more popular recently, so it seems time to look
> at some enhancements that would improve pg_migrator. None of these are
> required, but rather changes that would be nice to have:
>
> 1) Right now pg_migrator preserves relfilenodes for TOAST files be
Bruce,
Sorry for not having replied sooner...
On Sun, Jan 3, 2010 at 5:43 PM, Bruce Momjian wrote:
>> 1) Right now pg_migrator preserves relfilenodes for TOAST files because
>> this is required for proper migration. Now that we have shown that
>> strategically-placed global variables with a se
Bruce Momjian wrote:
> pg_migrator has become more popular recently, so it seems time to look
> at some enhancements that would improve pg_migrator. None of these are
> required, but rather changes that would be nice to have:
>
> 1) Right now pg_migrator preserves relfilenodes for TOAST files be
pg_migrator has become more popular recently, so it seems time to look
at some enhancements that would improve pg_migrator. None of these are
required, but rather changes that would be nice to have:
1) Right now pg_migrator preserves relfilenodes for TOAST files because
this is required for prop
50 matches
Mail list logo
