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 before
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
Tom Lane wrote:
Peter Eisentraut pete...@gmx.net 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
Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
On mC3A5n, 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.
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.
bikeshedding
Why -o and not, say, -Z? I imagine you picked -o for only but it
seems strange.
/
--
Alvaro Herrera
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.
bikeshedding
Why -o and not, say, -Z? I imagine you picked -o for only but it
seems strange.
/
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
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 every
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
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 both have the
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
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
Peter Eisentraut pete...@gmx.net 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
Tom Lane wrote:
Bruce Momjian br...@momjian.us 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
Bruce Momjian br...@momjian.us 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,
Tom Lane wrote:
Bruce Momjian br...@momjian.us 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
On Tue, Jan 5, 2010 at 11:06 AM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Tom Lane wrote:
Bruce Momjian br...@momjian.us 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
Robert Haas robertmh...@gmail.com writes:
On Tue, Jan 5, 2010 at 11:06 AM, Alvaro Herrera
alvhe...@commandprompt.com 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
Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
On Tue, Jan 5, 2010 at 11:06 AM, Alvaro Herrera
alvhe...@commandprompt.com 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
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 preserves
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 preserves
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 if there
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 were
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
Alvaro Herrera alvhe...@commandprompt.com 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
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 which
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 command which did
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 migration.
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 you
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 preserves
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 require some
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 ... Is
Bruce Momjian br...@momjian.us 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
On Mon, Jan 4, 2010 at 2:11 PM, Bruce Momjian br...@momjian.us 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
Tom Lane wrote:
Bruce Momjian br...@momjian.us 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
Robert Haas wrote:
On Mon, Jan 4, 2010 at 2:11 PM, Bruce Momjian br...@momjian.us 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
On Mon, Jan 4, 2010 at 2:52 PM, Bruce Momjian br...@momjian.us wrote:
Robert Haas wrote:
On Mon, Jan 4, 2010 at 2:11 PM, Bruce Momjian br...@momjian.us wrote:
Alvaro Herrera wrote:
2) ?Right now pg_migrator renames old tablespaces to .old, which fails
if the tablespaces are on mount
Robert Haas wrote:
On Mon, Jan 4, 2010 at 2:52 PM, Bruce Momjian br...@momjian.us wrote:
Robert Haas wrote:
On Mon, Jan 4, 2010 at 2:11 PM, Bruce Momjian br...@momjian.us wrote:
Alvaro Herrera wrote:
2) ?Right now pg_migrator renames old tablespaces to .old, which fails
if the
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 tablespaces due
to
On Mon, Jan 4, 2010 at 3:33 PM, Bruce Momjian br...@momjian.us wrote:
Robert Haas wrote:
On Mon, Jan 4, 2010 at 2:52 PM, Bruce Momjian br...@momjian.us wrote:
Robert Haas wrote:
On Mon, Jan 4, 2010 at 2:11 PM, Bruce Momjian br...@momjian.us wrote:
Alvaro Herrera wrote:
2) ?Right now
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 same, so we had better
On Mon, Jan 4, 2010 at 4:53 PM, Bruce Momjian br...@momjian.us 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 new
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 problem is that we are
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
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
Bruce Momjian br...@momjian.us 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
Bruce Momjian br...@momjian.us 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
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
Bruce,
Sorry for not having replied sooner...
On Sun, Jan 3, 2010 at 5:43 PM, Bruce Momjian br...@momjian.us 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
49 matches
Mail list logo
