Обсуждение: pg_migrator mention in documentation
Now that pg_migrator is in beta (http://pgfoundry.org/frs/?group_id=1000235), I was wondering if we want to mention pg_migrator anywhere in our docs or release notes? Josh Berkus is already mentioning it in the draft press release. I expect a final pg_migrator 8.4 release by the end of next week, before we release Postgres RC1. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Bruce Momjian wrote: > Now that pg_migrator is in beta (http://pgfoundry.org/frs/?group_id=1000235), > I was wondering if we want to mention pg_migrator anywhere in our docs > or release notes? Josh Berkus is already mentioning it in the draft > press release. Having gotten no replies I assume we don't want to mention pg_migrator in the release notes or documentation, which is fine. It is mentioned in the press release. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
On Saturday 06 June 2009 16:21:22 Bruce Momjian wrote: > Bruce Momjian wrote: > > Now that pg_migrator is in beta > > (http://pgfoundry.org/frs/?group_id=1000235), I was wondering if we want > > to mention pg_migrator anywhere in our docs or release notes? Josh > > Berkus is already mentioning it in the draft press release. > > Having gotten no replies I assume we don't want to mention pg_migrator > in the release notes or documentation, which is fine. It is mentioned > in the press release. Will you eventually want to ship pg_migrator in contrib? If so, then documentation will be added when that happens. If not, we should add a link somewhere where the upgrade process is described (installation instructions, I think). The makefile for pg_migrator currently assumes by default that it is located under contrib/. Which confuses me.
On Sat, 6 Jun 2009, Bruce Momjian wrote: > Having gotten no replies I assume we don't want to mention pg_migrator > in the release notes or documentation, which is fine. I know this project has resistance to putting URL links in the documentation. One option I was thinking about was creating some dedicated pages on the Wiki to hold resource pages for things like pg_migrator, which are extremely useful but are still in flux at the time when the release goes out. We could create a "Version Upgrade Resources" page, link to pg_migrator there, and include links to other related resources there too. The documentation could just say "There are external tools available to upgrade between versions in some circumstances without a dump and reload, see http://wiki.postgresql.org/wiki/Version_Upgrade_Resources for more information". That seems like a much more sustainable and permanent way to handle tools like this than directly linking to a project page for them, and gives capabilities like locking the page in order to prevent vandalism. Two other areas which I'd like to see "packaged" formally for reference in the docs like this are a page listing replication tools and one listing postgresql.conf tuning resources. Some of the known big problems with PosgreSQL have useful solutions, just not integrated ones yet, and we really should make it easier to popularize linking to those external tools in a controlled way. I'd be happy to create proposed pages for each of these topics on the wiki if this idea seems reasonable to the community, there are rough articles there already for all three ideas I can pull from. -- * Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD
Peter Eisentraut wrote: > On Saturday 06 June 2009 16:21:22 Bruce Momjian wrote: > > Bruce Momjian wrote: > > > Now that pg_migrator is in beta > > > (http://pgfoundry.org/frs/?group_id=1000235), I was wondering if we want > > > to mention pg_migrator anywhere in our docs or release notes? Josh > > > Berkus is already mentioning it in the draft press release. > > > > Having gotten no replies I assume we don't want to mention pg_migrator > > in the release notes or documentation, which is fine. It is mentioned > > in the press release. > > Will you eventually want to ship pg_migrator in contrib? If so, then > documentation will be added when that happens. It is really up to the community, not me, what they want to do with the code. > If not, we should add a link somewhere where the upgrade process is described > (installation instructions, I think). I think the question is what do we want to do for 8.4, if anything, and then we can figure out what to do for later releases. > The makefile for pg_migrator currently assumes by default that it is located > under contrib/. Which confuses me. You can compile pg_migrator by copying it to /contrib, or using PGXS; both work. Read the 15-step install instructions for details: (7) Build pg_migratorFor pg_migrator source installs, keep in mind the compile must use the_new_ PostgreSQL source directoryand be installed in the new Postgresinstall directory.The simplest build option is to point to the top of the PostgreSQLsourcetree by running something like: gmake top_builddir=/usr/src/pgsql installReplace '/usr/src/pgsql'with your source directory. pg_migrator alsounderstands the 'prefix=' specification if you installed Postgresin acustom location. Another build option is to copy the pg_migratordirectory into contrib/pg_migrator in the newPostgreSQL source tree andrun a simple 'gmake install'. A third install method is to use PGXS(assuming the new 'pg_config'is in your $PATH): USE_PGXS=1 gmake prefix=/usr/local/pgsql.new install -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
On Friday 19 June 2009 00:56:42 Bruce Momjian wrote: > > The makefile for pg_migrator currently assumes by default that it is > > located under contrib/. Which confuses me. > > You can compile pg_migrator by copying it to /contrib, or using PGXS; > both work. Read the 15-step install instructions for details: > > (7) Build pg_migrator > > For pg_migrator source installs, keep in mind the compile must use the > _new_ PostgreSQL source directory and be installed in the new Postgres > install directory. > > The simplest build option is to point to the top of the PostgreSQL > source tree by running something like: > > gmake top_builddir=/usr/src/pgsql install > > Replace '/usr/src/pgsql' with your source directory. pg_migrator also > understands the 'prefix=' specification if you installed Postgres in a > custom location. Another build option is to copy the pg_migrator > directory into contrib/pg_migrator in the new PostgreSQL source tree and > run a simple 'gmake install'. A third install method is to use PGXS > (assuming the new 'pg_config' is in your $PATH): > > USE_PGXS=1 gmake prefix=/usr/local/pgsql.new install Maybe the latter method should be the default, as it matches better with how we encourage other extension modules to be built?
Peter Eisentraut wrote: > On Friday 19 June 2009 00:56:42 Bruce Momjian wrote: > > > > The makefile for pg_migrator currently assumes by default that it is > > > located under contrib/. Which confuses me. > > > > You can compile pg_migrator by copying it to /contrib, or using PGXS; > > both work. Read the 15-step install instructions for details: > > > > (7) Build pg_migrator > > > > For pg_migrator source installs, keep in mind the compile must use the > > _new_ PostgreSQL source directory and be installed in the new Postgres > > install directory. > > > > The simplest build option is to point to the top of the PostgreSQL > > source tree by running something like: > > > > gmake top_builddir=/usr/src/pgsql install > > > > Replace '/usr/src/pgsql' with your source directory. pg_migrator also > > understands the 'prefix=' specification if you installed Postgres in a > > custom location. Another build option is to copy the pg_migrator > > directory into contrib/pg_migrator in the new PostgreSQL source tree and > > run a simple 'gmake install'. A third install method is to use PGXS > > (assuming the new 'pg_config' is in your $PATH): > > > > USE_PGXS=1 gmake prefix=/usr/local/pgsql.new install > > Maybe the latter method should be the default, as it matches better with how > we encourage other extension modules to be built? I wonder why we have two ways at all (I'm not counting the stuff about copying it to contrib because it seems pointless). The other day I was looking at orafce code in pgfoundry, and at clearxlogtail too IIRC, and they both had the "ifdef USE_PGXS" stuff in the Makefile. I wonder why. Why not just rip the "ifdef" line and the non-PGXS code, and just use PGXS always? It seems to me like module authors are just copying the contrib Makefiles without stopping to think that the Makefiles could be a lot shorter if they got rid of the non-PGXS part, which provides no extra value. More concretely, *** Makefile.orig 2009-07-02 14:35:03.000000000 -0400 --- Makefile 2009-07-02 14:35:08.000000000 -0400 *************** *** 15,26 **** PG_CPPFLAGS += -g -O0 -Wall -Wmissing-prototypes -Wmissing-declarations -Wpointer-arith -Wcast-align endif - ifdef USE_PGXS PGXS := $(shell pg_config --pgxs) include $(PGXS) - else - subdir = contrib/pg_migrator/src - top_builddir = ../../.. - include $(top_builddir)/src/Makefile.global - include $(top_srcdir)/contrib/contrib-global.mk - endif --- 15,19 ---- -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Alvaro Herrera <alvherre@commandprompt.com> wrote: > I wonder why we have two ways at all (I'm not counting the stuff > about copying it to contrib because it seems pointless). The other > day I was looking at orafce code in pgfoundry, and at clearxlogtail > too IIRC, and they both had the "ifdef USE_PGXS" stuff in the > Makefile. I wonder why. Why not just rip the "ifdef" line and the > non-PGXS code, and just use PGXS always? Well, most of our database servers wind up with multiple builds of PostgreSQL, and we find it is less error-prone for the non-programmer DBAs to expand a tarball under such a directory from the normal build (for the appropriate version) and make it there. There also seemed some possibility that clearxlogtail would be accepted into the distribution as a contrib module, so I was trying to have it ready to go, should that happen. As an aside, our function for extracting text from a PDF in a bytea didn't work right when I tried to build it using the PGXS the other day. I moved the directory into our PostgreSQL build location and built it the other way and it worked. I haven't tracked down why, but it leaves me leery of carving out the form which worked for me. (When you don't really understand something, you resort to superstitious ritual....) -Kevin
Peter Eisentraut <peter_e@gmx.net> writes:
> On Friday 19 June 2009 00:56:42 Bruce Momjian wrote:
>> A third install method is to use PGXS
>> (assuming the new 'pg_config' is in your $PATH):
>>
>> USE_PGXS=1 gmake prefix=/usr/local/pgsql.new install
> Maybe the latter method should be the default, as it matches better with how
> we encourage other extension modules to be built?
Also, the recommendation to specify prefix here is redundant and
error-prone. It can get the correct prefix from pg_config.
regards, tom lane
Peter Eisentraut wrote: > On Friday 19 June 2009 00:56:42 Bruce Momjian wrote: > > > > The makefile for pg_migrator currently assumes by default that it is > > > located under contrib/. Which confuses me. > > > > You can compile pg_migrator by copying it to /contrib, or using PGXS; > > both work. Read the 15-step install instructions for details: > > > > (7) Build pg_migrator > > > > For pg_migrator source installs, keep in mind the compile must use the > > _new_ PostgreSQL source directory and be installed in the new Postgres > > install directory. > > > > The simplest build option is to point to the top of the PostgreSQL > > source tree by running something like: > > > > gmake top_builddir=/usr/src/pgsql install > > > > Replace '/usr/src/pgsql' with your source directory. pg_migrator also > > understands the 'prefix=' specification if you installed Postgres in a > > custom location. Another build option is to copy the pg_migrator > > directory into contrib/pg_migrator in the new PostgreSQL source tree and > > run a simple 'gmake install'. A third install method is to use PGXS > > (assuming the new 'pg_config' is in your $PATH): > > > > USE_PGXS=1 gmake prefix=/usr/local/pgsql.new install > > Maybe the latter method should be the default, as it matches better with how > we encourage other extension modules to be built? I looked at that and the problem is that pg_migrator must be built against the _new_ source tree, and will issue an error and exit if it isn't. The problem with PGXS is it silently chooses the source tree to use based on which pg_config it finds in its path first; that seems error-prone. Any ideas for a clearer way to specify pg_config, and is that really helping things if the user has to specify it? As you can see, pg_migrator has the requirement of running in a multi-pg_config binary environment, so it has extra complexity that might make pg_config an undesirable option to be promoted first. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Tom Lane wrote: > Peter Eisentraut <peter_e@gmx.net> writes: > > On Friday 19 June 2009 00:56:42 Bruce Momjian wrote: > >> A third install method is to use PGXS > >> (assuming the new 'pg_config' is in your $PATH): > >> > >> USE_PGXS=1 gmake prefix=/usr/local/pgsql.new install > > > Maybe the latter method should be the default, as it matches better with how > > we encourage other extension modules to be built? > > Also, the recommendation to specify prefix here is redundant and > error-prone. It can get the correct prefix from pg_config. Again, see my email just posted about using pg_migrator in a multi-pg_config-binary environment. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Bruce Momjian <bruce@momjian.us> writes:
> Tom Lane wrote:
>> Also, the recommendation to specify prefix here is redundant and
>> error-prone. It can get the correct prefix from pg_config.
> Again, see my email just posted about using pg_migrator in a
> multi-pg_config-binary environment.
What's your point? If the wrong pg_config is first in the path,
PGXS will do the wrong things anyway. Specifying install prefix
manually is not enough to prevent that.
If the pg_migrator makefiles conformed to the accepted syntax for
PGXS invocation (click click ... which they do now) then the preferred
solution for this would be to explicitly specify the pg_config
location, *and nothing else*, on the make command line.
gmake USE_PGXS=1 PG_CONFIG=/path/to/pg_config install
I'm inclined to agree with Peter that the current documentation
is just going to confuse people by giving them too many options.
I would agree with removing the "ifdef USE_PGXS" from the makefiles
so that the USE_PGXS=1 bit can go away, and then saying
If the new installation's pg_config is first in your path,you can just say gmake installOtherwise, or to be extra
sure,say gmake PG_CONFIG=/path/to/pg_config install
(Although actually, if that pg_config isn't in your path, the
installed pg_migrator won't be either. It might be better to just
say "fix things so that the new installation's executables are
first in your PATH", and be done with it.)
regards, tom lane
Tom Lane wrote: > Bruce Momjian <bruce@momjian.us> writes: > > Tom Lane wrote: > >> Also, the recommendation to specify prefix here is redundant and > >> error-prone. It can get the correct prefix from pg_config. > > > Again, see my email just posted about using pg_migrator in a > > multi-pg_config-binary environment. > > What's your point? If the wrong pg_config is first in the path, > PGXS will do the wrong things anyway. Specifying install prefix > manually is not enough to prevent that. I already tell them to make sure the new one is first in the path: A third install method is to use PGXS (assuming the new 'pg_config'is the first 'pg_config' in your $PATH): > If the pg_migrator makefiles conformed to the accepted syntax for > PGXS invocation (click click ... which they do now) then the preferred Good, thanks. > solution for this would be to explicitly specify the pg_config > location, *and nothing else*, on the make command line. > > gmake USE_PGXS=1 PG_CONFIG=/path/to/pg_config install OK, I have updated the INSTALL file to use that and not tell them to modify their path. > I'm inclined to agree with Peter that the current documentation > is just going to confuse people by giving them too many options. > I would agree with removing the "ifdef USE_PGXS" from the makefiles > so that the USE_PGXS=1 bit can go away, and then saying > > If the new installation's pg_config is first in your path, > you can just say > gmake install > Otherwise, or to be extra sure, say > gmake PG_CONFIG=/path/to/pg_config install > > (Although actually, if that pg_config isn't in your path, the > installed pg_migrator won't be either. It might be better to just > say "fix things so that the new installation's executables are > first in your PATH", and be done with it.) I am betting many people will do src/pg_migrator to run it. However, there will be no pg_migrator binary in the old cluster (hopefully) so it would still find it even it the new cluster is not first in the path. Here is the new text I am using: The simplest build option is to use PGXS: gmake USE_PGXS=1 PG_CONFIG=/usr/local/pgsql/bin/pg_configinstallAnotheroption is to point to the top of the new PostgreSQL source treeby runningsomething like: gmake top_builddir=/usr/src/pgsql installReplace '/usr/src/pgsql' with your new source directory. pg_migratoralso understands the 'prefix=' specification if you installed Postgresin a custom location. I am happy to remove the USE_PGXS from the Makefile, but it seems all the other extensions require that so I want to be consistent. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Bruce Momjian <bruce@momjian.us> writes:
> Tom Lane wrote:
>> (Although actually, if that pg_config isn't in your path, the
>> installed pg_migrator won't be either. It might be better to just
>> say "fix things so that the new installation's executables are
>> first in your PATH", and be done with it.)
> I am betting many people will do src/pg_migrator to run it. However,
> there will be no pg_migrator binary in the old cluster (hopefully) so it
> would still find it even it the new cluster is not first in the path.
That's not a very future-proof assumption...
regards, tom lane
Tom Lane wrote: > Bruce Momjian <bruce@momjian.us> writes: > > Tom Lane wrote: > >> (Although actually, if that pg_config isn't in your path, the > >> installed pg_migrator won't be either. It might be better to just > >> say "fix things so that the new installation's executables are > >> first in your PATH", and be done with it.) > > > I am betting many people will do src/pg_migrator to run it. However, > > there will be no pg_migrator binary in the old cluster (hopefully) so it > > would still find it even it the new cluster is not first in the path. > > That's not a very future-proof assumption... Yep, but pg_migrator will exit quickly if an older version is run. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Bruce Momjian wrote: > I am happy to remove the USE_PGXS from the Makefile, but it seems all > the other extensions require that so I want to be consistent. Consistency here is pointless. IIRC the dual method is used in contrib because people did not trust the PGXS stuff enough to rip the original Make code out; or maybe because people did not want PGXS to become the default build method, but they allowed it to be used in contrib as a test bed that PGXS worked. As I pointed out earlier, this nonsense has crept out to external modules without better reason than being copied from contrib. The only problem I see with PGXS is that it cannot be used in certain situations where you want to have custom rules, but this is seldom the case. It would be better to get requests for PGXS enhancements so that it'd support those other cases too. Having PGXS is very useful to allow external modules to be built easily. Being forced to support the "in tree" method *plus* PGXS is pointless. -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Alvaro Herrera <alvherre@commandprompt.com> writes:
> Consistency here is pointless. IIRC the dual method is used in contrib
> because people did not trust the PGXS stuff enough to rip the original
> Make code out; or maybe because people did not want PGXS to become the
> default build method, but they allowed it to be used in contrib as a
> test bed that PGXS worked.
The main reason contrib still has the alternate method is that PGXS
doesn't really work until after you've installed the core build.
For modules distributed separately from core, it doesn't seem that
exciting to be able to build using the contrib method.
Now, having said that, I'm personally interested in being able to build
pg_migrator against an uninstalled source tree, because I foresee
needing to do that for RPM packaging purposes. But I could easily patch
the makefiles if needed to make that happen. I don't think this case
should drive the choice of what's the default or common method.
regards, tom lane
Tom Lane wrote: > Alvaro Herrera <alvherre@commandprompt.com> writes: > > Consistency here is pointless. IIRC the dual method is used in contrib > > because people did not trust the PGXS stuff enough to rip the original > > Make code out; or maybe because people did not want PGXS to become the > > default build method, but they allowed it to be used in contrib as a > > test bed that PGXS worked. > > The main reason contrib still has the alternate method is that PGXS > doesn't really work until after you've installed the core build. > For modules distributed separately from core, it doesn't seem that > exciting to be able to build using the contrib method. > > Now, having said that, I'm personally interested in being able to build > pg_migrator against an uninstalled source tree, because I foresee > needing to do that for RPM packaging purposes. But I could easily patch > the makefiles if needed to make that happen. I don't think this case > should drive the choice of what's the default or common method. Well, PGXS is now the recommended install method in the pg_migrator INSTALL file. What other changes should I make? -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Bruce Momjian wrote: > Tom Lane wrote: >> Alvaro Herrera <alvherre@commandprompt.com> writes: >>> Consistency here is pointless. IIRC the dual method is used in contrib >>> because people did not trust the PGXS stuff enough to rip the original >>> Make code out; or maybe because people did not want PGXS to become the >>> default build method, but they allowed it to be used in contrib as a >>> test bed that PGXS worked. >> The main reason contrib still has the alternate method is that PGXS >> doesn't really work until after you've installed the core build. >> For modules distributed separately from core, it doesn't seem that >> exciting to be able to build using the contrib method. >> >> Now, having said that, I'm personally interested in being able to build >> pg_migrator against an uninstalled source tree, because I foresee >> needing to do that for RPM packaging purposes. But I could easily patch >> the makefiles if needed to make that happen. I don't think this case >> should drive the choice of what's the default or common method. > > Well, PGXS is now the recommended install method in the pg_migrator > INSTALL file. What other changes should I make? Since PGXS does not work under Windows, I think the only way to build non-contrib extensions on Windows is the contrib way (i.e. place in contrib folder and use contrib style Makefile). Joe
On Fri, Jul 3, 2009 at 8:19 PM, Tom Lane<tgl@sss.pgh.pa.us> wrote: > The main reason contrib still has the alternate method is that PGXS > doesn't really work until after you've installed the core build. > For modules distributed separately from core, it doesn't seem that > exciting to be able to build using the contrib method. > > Now, having said that, I'm personally interested in being able to build > pg_migrator against an uninstalled source tree, because I foresee > needing to do that for RPM packaging purposes. But I could easily patch > the makefiles if needed to make that happen. I don't think this case > should drive the choice of what's the default or common method. Couldn't we provide a special pg_config and makefiles in the source tree which know the right paths and does the right thing for in-tree builds? -- greg http://mit.edu/~gsstark/resume.pdf
Joe Conway wrote: > Bruce Momjian wrote: > > Tom Lane wrote: > >> Alvaro Herrera <alvherre@commandprompt.com> writes: > >>> Consistency here is pointless. IIRC the dual method is used in contrib > >>> because people did not trust the PGXS stuff enough to rip the original > >>> Make code out; or maybe because people did not want PGXS to become the > >>> default build method, but they allowed it to be used in contrib as a > >>> test bed that PGXS worked. > >> The main reason contrib still has the alternate method is that PGXS > >> doesn't really work until after you've installed the core build. > >> For modules distributed separately from core, it doesn't seem that > >> exciting to be able to build using the contrib method. > >> > >> Now, having said that, I'm personally interested in being able to build > >> pg_migrator against an uninstalled source tree, because I foresee > >> needing to do that for RPM packaging purposes. But I could easily patch > >> the makefiles if needed to make that happen. I don't think this case > >> should drive the choice of what's the default or common method. > > > > Well, PGXS is now the recommended install method in the pg_migrator > > INSTALL file. What other changes should I make? > > Since PGXS does not work under Windows, I think the only way to build > non-contrib extensions on Windows is the contrib way (i.e. place in > contrib folder and use contrib style Makefile). I assume this work too: gmake top_builddir=/usr/src/pgsql install -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
On Friday 03 July 2009 02:28:22 Bruce Momjian wrote: > I looked at that and the problem is that pg_migrator must be built > against the _new_ source tree, and will issue an error and exit if it > isn't. The problem with PGXS is it silently chooses the source tree to > use based on which pg_config it finds in its path first; that seems > error-prone. Any ideas for a clearer way to specify pg_config, and is > that really helping things if the user has to specify it? The standard way to do that is make PG_CONFIG=/some/where/pg84/pg_config > As you can > see, pg_migrator has the requirement of running in a multi-pg_config > binary environment, so it has extra complexity that might make pg_config > an undesirable option to be promoted first. It's certainly easier to do the above than having to download, configure, and modify the PostgreSQL source tree, I think.
Peter Eisentraut wrote: > On Friday 03 July 2009 02:28:22 Bruce Momjian wrote: > > I looked at that and the problem is that pg_migrator must be built > > against the _new_ source tree, and will issue an error and exit if it > > isn't. The problem with PGXS is it silently chooses the source tree to > > use based on which pg_config it finds in its path first; that seems > > error-prone. Any ideas for a clearer way to specify pg_config, and is > > that really helping things if the user has to specify it? > > The standard way to do that is > > make PG_CONFIG=/some/where/pg84/pg_config > > > As you can > > see, pg_migrator has the requirement of running in a multi-pg_config > > binary environment, so it has extra complexity that might make pg_config > > an undesirable option to be promoted first. > > It's certainly easier to do the above than having to download, configure, and > modify the PostgreSQL source tree, I think. I see you are replying to an old email; the current installer instrutions are: (7) Build pg_migratorFor pg_migrator source installs, keep in mind the compile must use the_new_ PostgreSQL source directoryand be installed in the new Postgresinstall directory.The simplest build option is to use PGXS: gmake USE_PGXS=1PG_CONFIG=/usr/local/pgsql/bin/pg_config installAnother option is to point to the top of the new PostgreSQL sourcetreeby running something like: gmake top_builddir=/usr/src/pgsql installReplace '/usr/src/pgsql' with your newsource directory. pg_migratoralso understands the 'prefix=' specification if you installed Postgresin a custom location. pg_migrator does need a compiled backend source tree to be compiled, e.g. it needs libpgport and access to backend C defines. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. +