Re: [HACKERS] pg_migrator mention in documentation
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. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pg_migrator mention in documentation
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 br...@momjian.ushttp://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@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pg_migrator mention in documentation
On Fri, Jul 3, 2009 at 8:19 PM, Tom Lanet...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pg_migrator mention in documentation
Joe Conway wrote: Bruce Momjian wrote: Tom Lane wrote: Alvaro Herrera alvhe...@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 br...@momjian.ushttp://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@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pg_migrator mention in documentation
Bruce Momjian br...@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 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pg_migrator mention in documentation
Tom Lane wrote: Bruce Momjian br...@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_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 br...@momjian.ushttp://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@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pg_migrator mention in documentation
Bruce Momjian br...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pg_migrator mention in documentation
Tom Lane wrote: Bruce Momjian br...@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 br...@momjian.ushttp://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@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pg_migrator mention in documentation
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 Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pg_migrator mention in documentation
Alvaro Herrera alvhe...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pg_migrator mention in documentation
Tom Lane wrote: Alvaro Herrera alvhe...@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 br...@momjian.ushttp://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@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pg_migrator mention in documentation
Bruce Momjian wrote: Tom Lane wrote: Alvaro Herrera alvhe...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pg_migrator mention in documentation
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? -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pg_migrator mention in documentation
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.0 -0400 --- Makefile2009-07-02 14:35:08.0 -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 Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pg_migrator mention in documentation
Alvaro Herrera alvhe...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pg_migrator mention in documentation
Peter Eisentraut pete...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pg_migrator mention in documentation
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 br...@momjian.ushttp://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@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pg_migrator mention in documentation
Tom Lane wrote: Peter Eisentraut pete...@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 br...@momjian.ushttp://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@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pg_migrator mention in documentation
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. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pg_migrator mention in documentation
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 gsm...@gregsmith.com http://www.gregsmith.com Baltimore, MD -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pg_migrator mention in documentation
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 br...@momjian.ushttp://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@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pg_migrator mention in documentation
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 br...@momjian.ushttp://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@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] 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 br...@momjian.ushttp://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@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
