Thread: PostGIS vs. PGXS in 9.0beta3
Hackers, A 9.0b3 tester reported this issue with our single most popular PostgreSQL extension, PostGIS: ================== Postgis makes use of 'PGXS' in postgresql > 8.2. Within postgresql-9, datadir and many other variables are defined as multiple values with an append operator, like this: $ grep -i datadir /usr/pgsql-9.0/lib/pgxs/src/Makefile.global [snip] datadir := /usr/pgsql-9.0/share Postgis-1.5.1's Makefile.pgxs makefile override tries to use datadir as a flat variable, doesn't try to expand the array-like structure with a for loop or similar. So when 'make install' within postgis-1.5 configured against pgsql-9.x is ran, 'make' treats the second value within DATADIR as a command it should just run, which fails: http://postgis.refractions.net/pipermail/postgis-users/2010-May/026654.html I've tried the latest tarball SVN exports of both postgis-1.5.x and postgis-2.x without success. ================== I'm unsure of what the resolution of this issue should be ... it seems like the fix belongs in PostGIS ... but I also think we can't go final until this is resolved, given. -- -- Josh Berkus PostgreSQL Experts Inc. http://www.pgexperts.com
On Tue, Jul 27, 2010 at 1:13 PM, Josh Berkus <josh@agliodbs.com> wrote: > http://postgis.refractions.net/pipermail/postgis-users/2010-May/026654.html It's not obvious that there's an unresolved issue here; downthread there's some indication this might be an environment problem? http://postgis.refractions.net/pipermail/postgis-users/2010-May/026658.html -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company
Robert Haas wrote: > On Tue, Jul 27, 2010 at 1:13 PM, Josh Berkus <josh@agliodbs.com> wrote: > >> http://postgis.refractions.net/pipermail/postgis-users/2010-May/026654.html >> > > It's not obvious that there's an unresolved issue here; downthread > there's some indication this might be an environment problem? > > http://postgis.refractions.net/pipermail/postgis-users/2010-May/026658.html > > No, I have just reproduced this with a totally vanilla environment. I think PostGIS probably needs to patch their makefile(s). cheers andrew
Josh Berkus <josh@agliodbs.com> writes:
> A 9.0b3 tester reported this issue with our single most popular
> PostgreSQL extension, PostGIS:
> ==================
> Postgis makes use of 'PGXS' in postgresql > 8.2. Within postgresql-9,
> datadir and many other variables are defined as multiple values with an
> append operator, like this:
> $ grep -i datadir /usr/pgsql-9.0/lib/pgxs/src/Makefile.global
> [snip]
> datadir := /usr/pgsql-9.0/share
This analysis is nonsense on its face --- := is not an append operator
and we do not have any multiple values for datadir.
The referenced postgis-users thread seems to indicate that the postgis
guys found and fixed a problem in their own makefiles. If not, we need
a clearer description of what they think the problem is.
regards, tom lane
Tom Lane wrote: > Josh Berkus <josh@agliodbs.com> writes: > >> A 9.0b3 tester reported this issue with our single most popular >> PostgreSQL extension, PostGIS: >> > > >> ================== >> Postgis makes use of 'PGXS' in postgresql > 8.2. Within postgresql-9, >> datadir and many other variables are defined as multiple values with an >> append operator, like this: >> > > >> $ grep -i datadir /usr/pgsql-9.0/lib/pgxs/src/Makefile.global >> [snip] >> datadir := /usr/pgsql-9.0/share >> > > This analysis is nonsense on its face --- := is not an append operator > and we do not have any multiple values for datadir. > > The referenced postgis-users thread seems to indicate that the postgis > guys found and fixed a problem in their own makefiles. If not, we need > a clearer description of what they think the problem is. > The real problem has nothing to do with any of the analysis, as you say. It is this: they have an override file for PGXS and it uses $(mkinstalldirs) which we got rid of about a year ago. So apparently they haven't been testing much against any of our alphas or betas or they would have seen this long ago. The correct fix is to do the following in the PostGIS source root: sed -i -e 's/mkinstalldirs/MKDIR_P/' postgis/Makefile.pgxs cheers andrew
Andrew Dunstan wrote: > The real problem has nothing to do with any of the analysis, as you say. > It is this: they have an override file for PGXS and it uses > $(mkinstalldirs) which we got rid of about a year ago. So apparently > they haven't been testing much against any of our alphas or betas or > they would have seen this long ago. The correct fix is to do the > following in the PostGIS source root: > > sed -i -e 's/mkinstalldirs/MKDIR_P/' postgis/Makefile.pgxs > > cheers > > andrew Hmmm that's totally wrong - the override in Makefile.pgxs should only ever be loaded for PostgreSQL 8.3 and 8.4, and not PostgreSQL 9.0 since it already has the correct installation paths. What I suspect is that you're actually getting bitten by this: http://markmail.org/message/k7iolbazhrqhijfk#query:pg_config%20jun%202007+page:1+mid:rqk6ux2e7npqbrzf+state:results Or, in other words, configure is picking up the wrong pg_config. Since the path fix in the thread was not backported to < 8.3, then the presence of an another pg_config for PostgreSQL < 8.3 in PATH will break things :( ATB, Mark. -- Mark Cave-Ayland - Senior Technical Architect PostgreSQL - PostGIS Sirius Corporation plc - control through freedom http://www.siriusit.co.uk t: +44 870 608 0063 Sirius Labs: http://www.siriusit.co.uk/labs
Mark Cave-Ayland wrote: > Andrew Dunstan wrote: > >> The real problem has nothing to do with any of the analysis, as you >> say. It is this: they have an override file for PGXS and it uses >> $(mkinstalldirs) which we got rid of about a year ago. So apparently >> they haven't been testing much against any of our alphas or betas or >> they would have seen this long ago. The correct fix is to do the >> following in the PostGIS source root: >> >> sed -i -e 's/mkinstalldirs/MKDIR_P/' postgis/Makefile.pgxs >> >> cheers >> >> andrew > > Hmmm that's totally wrong - the override in Makefile.pgxs should only > ever be loaded for PostgreSQL 8.3 and 8.4, and not PostgreSQL 9.0 > since it already has the correct installation paths. > > What I suspect is that you're actually getting bitten by this: > > http://markmail.org/message/k7iolbazhrqhijfk#query:pg_config%20jun%202007+page:1+mid:rqk6ux2e7npqbrzf+state:results > > > Or, in other words, configure is picking up the wrong pg_config. Since > the path fix in the thread was not backported to < 8.3, then the > presence of an another pg_config for PostgreSQL < 8.3 in PATH will > break things :( No, the configure test is wrong. Here's what's in configure.ac: dnl Temporary hack until minimum PostgreSQL version is 8.5: dnl If PostgreSQL < 8.5 is detected, trigger the inclusionof the new versioned PGXS targets PGXSOVERRIDE=0 if test ! "$PGSQL_MINOR_VERSION" -ge 5; then PGXSOVERRIDE=1 fi Of course, we don't have any such thing as 8.5. cheers andrew
Andrew Dunstan wrote: > No, the configure test is wrong. Here's what's in configure.ac: > > > dnl Temporary hack until minimum PostgreSQL version is 8.5: > dnl If PostgreSQL < 8.5 is detected, trigger the inclusion of the > new versioned PGXS targets > PGXSOVERRIDE=0 > if test ! "$PGSQL_MINOR_VERSION" -ge 5; then > PGXSOVERRIDE=1 > fi > > > Of course, we don't have any such thing as 8.5. Ah wait - I see. The fix is in already in the 1.5 branch, it just hasn't hit a release yet :( http://trac.osgeo.org/postgis/changeset/5421/branches/1.5/configure.ac Looks like we need to push a new release in time for 9.0... ATB, Mark. -- Mark Cave-Ayland - Senior Technical Architect PostgreSQL - PostGIS Sirius Corporation plc - control through freedom http://www.siriusit.co.uk t: +44 870 608 0063 Sirius Labs: http://www.siriusit.co.uk/labs