pg_migrator issues
in [PgSql]
|
From: decibel on 6 Jan 2010 02:52 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 a single command which did this. I actually started on a patch for this (http://lnk.nu/archives.postgresql.org/14rm.php). IIRC it's pretty close, I just haven't had time to come back to it for final cleanup and changing the docs as needed. -- Jim C. Nasby, Database Architect jim(a)nasby.net 512.569.9461 (cell) http://jim.nasby.net -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Zdenek Kotala on 6 Jan 2010 10:00 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 require some odd C tricks. Add to that you >> don't know which version of Postgres you are migrating from/to during >> compile and the idea of using C becomes even less attractive. > > However, keep in mind that this might not be the last time on which we > will want to read something from a C struct, so perhaps it would be good > to bite the bullet and write the odd tricks. Does it already have > access (at compile time) to the old and new source trees? I have some proof of concept when each control data struct version version have one header file like pg_control_843.h and structure like ControlFileData has name ControlFileData_843. The main pg_control.h defines types without version like typedef ControlFileData_843 ControlFileData; I planed to do it for 8.5 but unfortunately no time :( commit fest is too close. Zdenek -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Bruce Momjian on 6 Jan 2010 11:11 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 same > >> structure names, that would require some odd C tricks. Add to that you > >> don't know which version of Postgres you are migrating from/to during > >> compile and the idea of using C becomes even less attractive. > > > > However, keep in mind that this might not be the last time on which we > > will want to read something from a C struct, so perhaps it would be good > > to bite the bullet and write the odd tricks. Does it already have > > access (at compile time) to the old and new source trees? > > I have some proof of concept when each control data struct version > version have one header file like pg_control_843.h and structure like > ControlFileData has name ControlFileData_843. The main pg_control.h > defines types without version like > > typedef ControlFileData_843 ControlFileData; > > I planed to do it for 8.5 but unfortunately no time :( commit fest is > too close. Yea, I think the confusion of doing it isn't worth it. -- Bruce Momjian <bruce(a)momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Bruce Momjian on 6 Jan 2010 12:59 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 only > if they want to keep the same $PGDATA value after migration, i.e. no > version-specific directory path. One idea we floated around was to have > tablespaces use major version directory names under the tablespace > directory so renaming would not be necessary. I could implement a > pg_migrator --delete-old flag to cleanly delete the old 8.4 server files > which are not in a version-specific subdirectory. FYI, pg_migrator CVS now uses the relfilenode preservation ability in 8.5 to avoid the creation of placeholder relfilenodes and renaming. It also recommends using vacuumdb --only-analyze. To simplify pg_migrator, you can now only migrate _to_ 8.5 as of today's CVS, not earlier 8.5 CVS trees. One interesting aspect of pg_migrator is that while it has to carry around support for upgrading _from_ many old releases, the target/to version support can stay limited, i.e. I doubt anyone is going to want to use pg_migrator to migrate to 8.4 in a year or two --- they will be migrating to 8.5. We can also consider removing 8.4 target migration support in pg_migrator 8.5 and just tell people they have to use pg_migrator 8.4.X for a migration to PG 8.4.X. -- Bruce Momjian <bruce(a)momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Peter Eisentraut on 7 Jan 2010 00:24
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 other options like --data-only, --schema-only, --tuples-only. I personally don't like the spelling of --only-analyze. -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |