Re: 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(at)agliodbs(dot)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(at)agliodbs(dot)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(at)agliodbs(dot)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(at)agliodbs(dot)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 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.

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