Re: 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(at)momjian(dot)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(at)momjian(dot)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(at)gregsmith(dot)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_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

--
Bruce Momjian <bruce(at)momjian(dot)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(at)commandprompt(dot)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(at)gmx(dot)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(at)momjian(dot)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(at)gmx(dot)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(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Bruce Momjian <bruce(at)momjian(dot)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 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.)

regards, tom lane

Tom Lane wrote:
> Bruce Momjian <bruce(at)momjian(dot)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_config
install


Another option is to point to the top of the new PostgreSQL source tree
by running something like:

gmake top_builddir=/usr/src/pgsql install

Replace '/usr/src/pgsql' with your new source directory. pg_migrator
also understands the 'prefix=' specification if you installed Postgres
in 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(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Bruce Momjian <bruce(at)momjian(dot)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(at)momjian(dot)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(at)momjian(dot)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(at)commandprompt(dot)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(at)commandprompt(dot)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(at)momjian(dot)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(at)commandprompt(dot)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(at)sss(dot)pgh(dot)pa(dot)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(at)commandprompt(dot)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(at)momjian(dot)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_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 use PGXS:

gmake USE_PGXS=1 PG_CONFIG=/usr/local/pgsql/bin/pg_config install


Another option is to point to the top of the new PostgreSQL source tree
by running something like:

gmake top_builddir=/usr/src/pgsql install

Replace '/usr/src/pgsql' with your new source directory. pg_migrator
also understands the 'prefix=' specification if you installed Postgres
in 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(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +