Horton

Thread

  1. RE: AW: Re: GiST for 7.1 !!

    Mikheev, Vadim <vmikheev@sectorbase.com> — 2001-01-11T23:59:42Z

    > > erk, can we get this somehow done in such a way that its part of the
> > *standard* regression tests?  so when ppl do 'make test',
> > the GiST stuff is checked also?  My worry, as with others, isn't that
> > GiST itself is broken by the changes, its that *somehow* there is an
> > interaction that is with the rest of the system that isn't being tested
...
> 
> No way, we need to load functions. there are several contributions
> which depends on loaded functions. If you suggest how to do this
> in general way, it would fine. To test GiST you need to define some
> data structure ( in our case - RD-tree) and functions to access it

Look at regress/input/create_function_1.source for hints from
SPI tests...

Vadim

  2. RE: AW: Re: GiST for 7.1 !!

    Oleg Bartunov <oleg@sai.msu.su> — 2001-01-12T00:18:08Z

     On Thu, 11 Jan 2001, Mikheev, Vadim wrote:

> > > erk, can we get this somehow done in such a way that its part of the
> > > *standard* regression tests?  so when ppl do 'make test',
> > > the GiST stuff is checked also?  My worry, as with others, isn't that
> > > GiST itself is broken by the changes, its that *somehow* there is an
> > > interaction that is with the rest of the system that isn't being tested
> ...
> >
> > No way, we need to load functions. there are several contributions
> > which depends on loaded functions. If you suggest how to do this
> > in general way, it would fine. To test GiST you need to define some
> > data structure ( in our case - RD-tree) and functions to access it
>
> Look at regress/input/create_function_1.source for hints from
> SPI tests...
>
Thanks Vadim for tips. Will do this way, but tommorow. It's
3:19 am already and I have to sleep :-)



> Vadim
>

	Regards,
		Oleg
_____________________________________________________________
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/
phone: +007(095)939-16-83, +007(095)939-23-83

  3. Re: AW: Re: GiST for 7.1 !!

    Tom Lane <tgl@sss.pgh.pa.us> — 2001-01-12T00:51:41Z

    Oleg Bartunov <oleg@sai.msu.su> writes:
>>>> No way, we need to load functions. there are several contributions
>>>> which depends on loaded functions. If you suggest how to do this
>>>> in general way, it would fine. To test GiST you need to define some
>>>> data structure ( in our case - RD-tree) and functions to access it
>> 
>> Look at regress/input/create_function_1.source for hints from
>> SPI tests...

Um, you do realize that a contrib module that gets used as part of the
regress tests may as well be mainstream?  At least in terms of the
portability requirements it will have to meet?

I'm unhappy again.  Bad enough we accepted a new feature during beta;
now we're going to expect an absolutely virgin contrib module to work
everywhere in order to pass regress tests?

			regards, tom lane

  4. Re: AW: Re: GiST for 7.1 !!

    Lamar Owen <lamar.owen@wgcr.org> — 2001-01-12T02:59:58Z

    Tom Lane wrote:
> Um, you do realize that a contrib module that gets used as part of the
> regress tests may as well be mainstream?  At least in terms of the
> portability requirements it will have to meet?
 
> I'm unhappy again.  Bad enough we accepted a new feature during beta;
> now we're going to expect an absolutely virgin contrib module to work
> everywhere in order to pass regress tests?

Last I checked, two contrib modules had to be built for regression
testing.  But that was 7.0. (autoinc and refint.....).
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

  5. Re: AW: Re: GiST for 7.1 !!

    Tom Lane <tgl@sss.pgh.pa.us> — 2001-01-12T03:08:12Z

    Lamar Owen <lamar.owen@wgcr.org> writes:
>> I'm unhappy again.  Bad enough we accepted a new feature during beta;
>> now we're going to expect an absolutely virgin contrib module to work
>> everywhere in order to pass regress tests?

> Last I checked, two contrib modules had to be built for regression
> testing.

Sure, but they've been there awhile.  All of my concerns here are
schedule-driven: do we really want to be wringing out a new contrib
module, to the point where it will run everywhere, before we can
release 7.1?

			regards, tom lane

  6. Re: AW: Re: GiST for 7.1 !!

    Lamar Owen <lamar.owen@wgcr.org> — 2001-01-12T03:15:10Z

    Tom Lane wrote:
> Lamar Owen <lamar.owen@wgcr.org> writes:
> >> I'm unhappy again.  Bad enough we accepted a new feature during beta;
> >> now we're going to expect an absolutely virgin contrib module to work
> >> everywhere in order to pass regress tests?
 
> > Last I checked, two contrib modules had to be built for regression
> > testing.
 
> Sure, but they've been there awhile.  All of my concerns here are
> schedule-driven: do we really want to be wringing out a new contrib
> module, to the point where it will run everywhere, before we can
> release 7.1?

Are the benefits worth the effort?  Can the current GiST developers pull
it off in time?

If the answer to either question is not a resounding YES then we really
don't need to go down this road.  Either leave it in contrib and
regression testless (with a test script in the contrib), or make it a
feature patch.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

  7. Re: AW: Re: GiST for 7.1 !!

    Marc G. Fournier <scrappy@hub.org> — 2001-01-12T03:29:47Z

    On Thu, 11 Jan 2001, Tom Lane wrote:

> Lamar Owen <lamar.owen@wgcr.org> writes:
> >> I'm unhappy again.  Bad enough we accepted a new feature during beta;
> >> now we're going to expect an absolutely virgin contrib module to work
> >> everywhere in order to pass regress tests?
>
> > Last I checked, two contrib modules had to be built for regression
> > testing.
>
> Sure, but they've been there awhile.  All of my concerns here are
> schedule-driven: do we really want to be wringing out a new contrib
> module, to the point where it will run everywhere, before we can
> release 7.1?

Hrmmm ... just a thought here, but how about a potential 'interactive'
regression test, where it asks if you want to run regress on GiST?  If so,
do it, if not, ignore it ... ?

  8. Re: AW: Re: GiST for 7.1 !!

    Thomas Lockhart <lockhart@alumni.caltech.edu> — 2001-01-12T15:10:38Z

    > IMHO, giving out real test results, even negative, instead of leaving
> things untested would be a honest thing to do.

afaict there are several concerns or decisions, and we've made a few
already:

Re: gist.c patches...

1) Oleg and Hannu are committed to testing the repaired GiST as soon as
it is in the main tree. They are both testing already with the patched
version.

2) They will try to contact Gene to encourage testing with Gene's
application, though they have no reason to suspect from their own
testing that Gene's stuff will break.

3) There is a consensus that the gist.c patches should appear in the 7.1
release, to allow useful work with GiST and to enable further
development. So it is OK to commit the gist.c patches based on Oleg's
and Hannu's existing and future test plan.

Re: regression tests...

4) We all would like to see some regression tests of GiST. Tom Lane has
(rightly) expressed concern over unforeseen breakage in the regression
flow when done on other platforms.

5) Oleg has some regression-capable test code available for contrib, but
has indicated that fully (re)writing the regression tests will take too
much time.

6) We have at least two committed testers for the 7.1 release for the
GiST features. That is two more than we've ever had before (afacr Gene
didn't participate in the end-stage beta cycle, but I may not be
remembering correctly) so the risks that something is not right are
greatly reduced, to below the risks of same on the day of release for
previous versions.

8) Additional regression testing is required asap, but may not be
allowed into the default 7.1 test sequence.

How about adding an optional test a la "bigtest" for GiST for this
release? It could go mainstream for 7.1.x or for 7.2 as we get more
experience with it. This is just a suggestion and I'm sure there are
other possibilities. I'm pretty sure we agree on most of points 1-8, and
that 1-3 are resolved. Comments?

                      - Thomas

  9. Re: AW: Re: GiST for 7.1 !!

    Marc G. Fournier <scrappy@hub.org> — 2001-01-12T15:21:13Z

    On Fri, 12 Jan 2001, Thomas Lockhart wrote:

> How about adding an optional test a la "bigtest" for GiST for this
> release? It could go mainstream for 7.1.x or for 7.2 as we get more
> experience with it. This is just a suggestion and I'm sure there are
> other possibilities. I'm pretty sure we agree on most of points 1-8, and
> that 1-3 are resolved. Comments?

make GIST_TEST=yes

to include GiST testing would be cool, if it can be done ... this way
Tom's worry about non-GiST users having bad regress tests is appeased ...
but I do agree with Tom that mainstreaming the GiST testing would be a bad
idea ... if we could somehow include it as an optional test (as you say,
ala bigtest), then, if nothing else, it saves having to cd to the contrib
directory and run it there ... ala one stop shopping ...

*But*, for the 3 ppl we've pointed out as users of GiST, this is
definitely not a priority issue ... if we can do it, great, if not, no
sweat either ...

  10. Re: AW: Re: GiST for 7.1 !!

    Tom Lane <tgl@sss.pgh.pa.us> — 2001-01-12T15:27:21Z

    Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
> How about adding an optional test a la "bigtest" for GiST for this
> release?

We could do that, but it seems like rather pointless effort, compared
to just telling people "go run the tests in these contrib modules if
you want to test GIST".

I have no objection to fully integrating some GIST test(s) for 7.2.
I just don't want to deal with it at this late stage of the 7.1 cycle.
We have a long list of considerably more mainstream to-do items yet
to deal with ...

			regards, tom lane

  11. Re: AW: Re: GiST for 7.1 !!

    Hannu Krosing <hannu@tm.ee> — 2001-01-12T16:01:55Z

    Tom Lane wrote:
> 
> Um, you do realize that a contrib module that gets used as part of the
> regress tests may as well be mainstream?  At least in terms of the
> portability requirements it will have to meet?

_If_ we want to have a tested GiST (and not the "probably works but 
really has some nasty known bugs" one) we need to write _tests_.

To test it we need something that makes use of it.

As the only things that make use of it are extensions we need to 
make use of them in tests.

So I propose the following : 
1. Keep the fixed (new) gist.c in the main codebase
2. make use of the RD-index and/or Gene's tests in contrib in regression
tests
3. Tellpeople beforehand that it is not the end of the world
   if GiST _tests_ fail on their platform

> I'm unhappy again.  Bad enough we accepted a new feature during beta;
> now we're going to expect an absolutely virgin contrib module to work
> everywhere in order to pass regress tests?

There can be always "expected" discrepancies in regress tests, and 
failing GiST test just tells people that if they want to use GiST on 
their platform they must probably fix things in core code as well.
Currently they have to find it out the hard way - first lot of work 
trying to "fix" their own code and only then the bright idea that 
maybe it is actually broken in the core.

IMHO, giving out real test results, even negative, instead of leaving 
things untested would be a honest thing to do.

-----------------
Hannu

  12. Re: Re: AW: Re: GiST for 7.1 !!

    Peter Eisentraut <peter_e@gmx.net> — 2001-01-12T16:13:46Z

    Thomas Lockhart writes:

> How about adding an optional test a la "bigtest" for GiST for this
> release?

An optional test is like no test at all.  No one runs optional tests.  If
the test is supposed to work then it should be mainstream.  If the test
might not work then you better go back and figure out what you're testing.
If the test might not *compile* (which is probably the more severe problem
that people are concerned about) then this idea won't help that at all
unless you want to rework the regression test driver framework as well.

-- 
Peter Eisentraut      peter_e@gmx.net       http://yi.org/peter-e/

  13. Re: Re: AW: Re: GiST for 7.1 !!

    Thomas Lockhart <lockhart@alumni.caltech.edu> — 2001-01-12T16:29:29Z

    > An optional test is like no test at all.  No one runs optional tests.  If
> the test is supposed to work then it should be mainstream.  If the test
> might not work then you better go back and figure out what you're testing.
> If the test might not *compile* (which is probably the more severe problem
> that people are concerned about) then this idea won't help that at all
> unless you want to rework the regression test driver framework as well.

I agree completely. This is just a transition phase to get GiST into the
mainstream.

                   - Thomas

  14. Re: AW: Re: GiST for 7.1 !!

    Marc G. Fournier <scrappy@hub.org> — 2001-01-12T16:55:06Z

    On Fri, 12 Jan 2001, Tom Lane wrote:

> Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
> > How about adding an optional test a la "bigtest" for GiST for this
> > release?
>
> We could do that, but it seems like rather pointless effort, compared
> to just telling people "go run the tests in these contrib modules if
> you want to test GIST".
>
> I have no objection to fully integrating some GIST test(s) for 7.2.
> I just don't want to deal with it at this late stage of the 7.1 cycle.
> We have a long list of considerably more mainstream to-do items yet
> to deal with ...

Not up to us to deal with, its up to Oleg ...

Oleg, if you could work on and submit patches for this before the release,
that would be appreciated ... it might also serve to increase visibility
of GiST if ppl know there is a regress test for it ...

  15. Re: Re: AW: Re: GiST for 7.1 !!

    selkovjr@mcs.anl.gov — 2001-01-13T23:31:25Z

    I am sorry I wasn't listening -- I may have helped by at least
answering the direct questions and by testing. I have, in fact,
positively tested both my and Oleg's code in the today's snapshot on a
number of linux and FreeBSD systems. I failed on this one:

SunOS typhoon 5.7 Generic_106541-10 sun4u sparc SUNW,Ultra-1

on which configure didn't detect the absence of libz.so

I don't think my applications are affected by Oleg's changes. But I
understand the tension that occurred during the past few days and even
though I am now satisfied with the agreement you seem to have
achieved, I could have hardly influenced it in any reasonable way. I
am as sympathetic with the need for a smooth an solid code control as
I am with promoting great features (or, in this case, just keeping a
feature alive). So, if I were around at the time I was asked to vote,
I wouldn't know how. I usually find it difficult to take sides in
"Motherhood vs. Clean Air" debates. It is true that throwing a core
during a regression test does gives one a black eye. It is also true
that there are probably hundreds of possible users, ignorant of the
GiST, trying to invent surrogate solutions. As far as I am concerned,
I will be satisfied with whatever solution you arrive at. I am pleased
that in this neighborhood, reason prevails over faith.

--Gene

  16. Re: Re: AW: Re: GiST for 7.1 !!

    Tom Lane <tgl@sss.pgh.pa.us> — 2001-01-14T03:13:56Z

    selkovjr@mcs.anl.gov writes:
> I am sorry I wasn't listening -- I may have helped by at least
> answering the direct questions and by testing. I have, in fact,
> positively tested both my and Oleg's code in the today's snapshot on a
> number of linux and FreeBSD systems. I failed on this one:

> SunOS typhoon 5.7 Generic_106541-10 sun4u sparc SUNW,Ultra-1

> on which configure didn't detect the absence of libz.so

Really?  Details please.  It's hard to see how it could have messed
up on that.

			regards, tom lane

  17. R-Tree implementation using GiST

    Oleg Bartunov <oleg@sai.msu.su> — 2001-01-14T15:41:10Z

    Hi,

I've put R-Tree realization using GiST (yet another test of our changes in
gist code )on my gist page http://www.sai.msu.su/~megera/postgres/gist/
Also, I've put some GiST related papers for interested readers.
The package( contrib-rtree_box_gist.tar.gz ) is built for 7.1.
If you find it's interesting you may include it into contrib area for 7.1

from README.rtree_box_gist:


1. One interesting thing is that insertion time for built-in R-Tree is
   about 8 times more than ones for GiST implementation of R-Tree !!!
2. Postmaster requires much more memory for built-in R-Tree
3. Search time depends on dataset. In our case we got:
        +------------+-----------+--------------+
        |Number boxes|R-tree, sec|R-tree using  |
        |            |           |   GiST, sec  |
        +------------+-----------+--------------+
        |          10|      0.002|         0.002|
        +------------+-----------+--------------+
        |         100|      0.002|         0.002|
        +------------+-----------+--------------+
        |        1000|      0.002|         0.002|
        +------------+-----------+--------------+
        |       10000|      0.015|         0.025|
        +------------+-----------+--------------+
        |       20000|      0.029|         0.048|
        +------------+-----------+--------------+
        |       40000|      0.055|         0.092|
        +------------+-----------+--------------+
        |       80000|      0.113|         0.178|
        +------------+-----------+--------------+
        |      160000|      0.338|         0.337|
        +------------+-----------+--------------+
        |      320000|      0.674|         0.673|
        +------------+-----------+--------------+


	Regards,
		Oleg
_____________________________________________________________
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/
phone: +007(095)939-16-83, +007(095)939-23-83

  18. Re: Re: AW: Re: GiST for 7.1 !!

    Tom Lane <tgl@sss.pgh.pa.us> — 2001-01-15T05:58:02Z

    selkovjr@mcs.anl.gov writes:
>>>> on which configure didn't detect the absence of libz.so
>> 
>> Really?  Details please.  It's hard to see how it could have messed
>> up on that.

> I didn't look well enough -- I apologize. The library is there, but
> ld.so believes it is not:

> typhoon> postmaster 
> ld.so.1: postmaster: fatal: libz.so: open failed: No such file or directory
> Killed

Odd.  Can you show us the part of config.log that relates to zlib?
It's strange that configure's check to see if zlib is linkable should
succeed, only to have the live startup fail.  Is it possible that
you ran configure with a different library search path (LD_LIBRARY_PATH
or local equivalent) than you are using now?

It's suspicious that the error message mentions libz.so when the actual
file name is libz.so.1, but I still don't see how that could result in
configure's link test succeeding but the executable not running.

			regards, tom lane

  19. Re: Re: AW: Re: GiST for 7.1 !!

    selkovjr@mcs.anl.gov — 2001-01-15T06:39:01Z

    > Tom Lane writes:
> > selkovjr@mcs.anl.gov writes:
...
> > SunOS typhoon 5.7 Generic_106541-10 sun4u sparc SUNW,Ultra-1
> 
> > on which configure didn't detect the absence of libz.so
> 
> Really?  Details please.  It's hard to see how it could have messed
> up on that.

Tom, 

I didn't look well enough -- I apologize. The library is there, but
ld.so believes it is not:

typhoon> postmaster 
ld.so.1: postmaster: fatal: libz.so: open failed: No such file or directory
Killed

This may very well be just my ISP's problem.

Anyway, the details are:

1. My (relevant) environment:

LD_LIBRARY_PATH=/usr/openwin/lib:/usr/lib:/usr/ucblib:/usr/ccs/lib
PGLIB=/home/customer/selkovjr/pgsql/lib
PGDATA=/home/customer/selkovjr/pgsql/data
PATH=/usr/local/vendor/SUNWspro/bin:/usr/local/bin:/usr/local/gnu/bin:/usr/local/GNU/bin:/usr/sbin:/usr/bin:/usr/ccs/bin:/usr/ucb:/etc:/usr/etc:/usr/openwin/bin:/home/customer/selkovjr/bin:./usr/local/bin::/home/customer/selkovjr/pgsql/bin

2. I built postgres (from the snapshot of Jan 13) with:

./configure --prefix=/home/customer/selkovjr/pgsql
make
make install

3. initdb worked.

4. The library in question is in /usr/openwin/lib:

typhoon> ls -l /usr/openwin/lib | grep libz
-rwxr-xr-x   1 root     bin        97836 Sep 23  1999 libz.a
-rwxr-xr-x   1 root     bin        70452 Sep 23  1999 libz.so.1

I can't think of anything else. Is there a one-liner to test libz? I
believe I have successfully tested and run 6.5.3 in the same
environment.

--Gene

  20. Re: Re: AW: Re: GiST for 7.1 !!

    selkovjr@mcs.anl.gov — 2001-01-16T09:07:20Z

    Tom Lane writes:
> selkovjr@mcs.anl.gov writes:
> >>>> on which configure didn't detect the absence of libz.so
> >> 
> >> Really?  Details please.  It's hard to see how it could have messed
> >> up on that.
> 
> > I didn't look well enough -- I apologize. The library is there, but
> > ld.so believes it is not:
> 
> > typhoon> postmaster 
> > ld.so.1: postmaster: fatal: libz.so: open failed: No such file or directory
> > Killed
> 
> Odd.  Can you show us the part of config.log that relates to zlib?

configure:4179: checking for zlib.h
configure:4189: gcc -E   conftest.c >/dev/null 2>conftest.out
configure:4207: checking for inflate in -lz
configure:4226: gcc -o conftest      conftest.c -lz  -lgen -lnsl -lsocket -ldl -lm -lreadline -ltermcap -lcurses  1>&5
configure:4660: checking for crypt.h

This doesn't tell me much. But I modified configure to exit right
after this, without removing conftest*, and when I ran conftest it came
back with the same message:

typhoon> ./conftest
ld.so.1: ./conftest: fatal: libz.so: open failed: No such file or directory
Killed

> It's strange that configure's check to see if zlib is linkable should
> succeed, only to have the live startup fail. 

It is. In this line:

if { (eval echo configure:4226: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext}; then

why is conftest tested for size instead of being executed?

> Is it possible that
> you ran configure with a different library search path (LD_LIBRARY_PATH
> or local equivalent) than you are using now?

No, I didn't alter it. I am using the system-wide settings.

> It's suspicious that the error message mentions libz.so when the actual
> file name is libz.so.1, but I still don't see how that could result in
> configure's link test succeeding but the executable not running.

That puzzles me as well. It seems to be because there is no libz.so on
the system. For if I do this:

export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/home/customer/selkovjr/lib 
ln -s /usr/openwin/lib/libz.so.1 ~/lib/libz.so

the libz problem is gone, only to be followed by the next one:

typhoon> ./conftest
ld.so.1: ./conftest: fatal: libreadline.so: open failed: No such file or directory

The odd thing is, there is no libreadline.so* on this system. Here's the corresponding part of config.log:

configure:3287: checking for library containing readline
configure:3305: gcc -o conftest      conftest.c -ltermcap -lcurses  1>&5
Undefined                       first referenced
 symbol                             in file
readline                            /var/tmp/ccxxiW3R.o
ld: fatal: Symbol referencing errors. No output written to conftest
collect2: ld returned 1 exit status
configure: failed program was:
#line 3294 "configure"
#include "confdefs.h"
/* Override any gcc2 internal prototype to avoid an error.  */
/* We use char because int might match the return type of a gcc2
    builtin and then its argument prototype would still apply.  */
char readline();

int main() {
readline()
; return 0; }
configure:3327: gcc -o conftest      conftest.c -lreadline  -ltermcap -lcurses  
1>&5

This system is probaly badly misconfigured, but it would be great if
configure could see that. By the way, would you mind if I asked you to
log in and take a look? Is there a phone number where I can get you
with the password? I am not sure whether such tests could be of any
value, but it's the only Sun machine available to me for testing.

Thank you,

--Gene

  21. Getting configure to notice link-time vs run-time failures

    Tom Lane <tgl@sss.pgh.pa.us> — 2001-01-18T01:02:03Z

    selkovjr@mcs.anl.gov writes:
> configure:4207: checking for inflate in -lz
> configure:4226: gcc -o conftest      conftest.c -lz  -lgen -lnsl -lsocket -ldl -lm -lreadline -ltermcap -lcurses  1>&5
> configure:4660: checking for crypt.h

> This doesn't tell me much. But I modified configure to exit right
> after this, without removing conftest*, and when I ran conftest it came
> back with the same message:

> typhoon> ./conftest
> ld.so.1: ./conftest: fatal: libz.so: open failed: No such file or directory
> Killed

>> It's strange that configure's check to see if zlib is linkable should
>> succeed, only to have the live startup fail. 

> This system is probaly badly misconfigured, but it would be great if
> configure could see that.

Gene and I looked into this, and the cause of the misbehavior is this:
gcc on this installation is set to search /usr/local/lib (along with the
usual system library directories).  libz.so and libreadline.so are
indeed in /usr/local/lib, so configure's tests to see if they can be
linked against will succeed.  But he had LD_LIBRARY_PATH set to a list
that did *not* include /usr/local/lib, so actually firing up the
executable would fail.

As he says, it'd be nice if configure could either prevent this or at
least detect it.  Not sure about a good way to do that --- any ideas?

			regards, tom lane

  22. Re: Getting configure to notice link-time vs run-time failures

    Peter Eisentraut <peter_e@gmx.net> — 2001-01-18T23:46:53Z

    Tom Lane writes:

> Gene and I looked into this, and the cause of the misbehavior is this:
> gcc on this installation is set to search /usr/local/lib (along with the
> usual system library directories).  libz.so and libreadline.so are
> indeed in /usr/local/lib, so configure's tests to see if they can be
> linked against will succeed.  But he had LD_LIBRARY_PATH set to a list
> that did *not* include /usr/local/lib, so actually firing up the
> executable would fail.

You get what you pay for.  If you're running executables from configure
you're asking for it.

This setup is a poor man's cross-compilation situation because the system
you're compiling on is not identically configured to the system you're
going to run on.  (Strictly speaking, the behaviour of a test program
might even vary with different LD_LIBRARY_PATH settings.)

So

a)  PostgreSQL does not support cross-compilation (yet).  Too bad.

b)  We could get rid of all executition time checks in configure (to
    remedy (a)).  This is one of my plans for the future.

c)  You could move the execution time checks up before the suspicious
    library checks, but I'm afraid that this will only cure a particular
    symptom and might introduce other problems.

I'd say, you're stuck.

-- 
Peter Eisentraut      peter_e@gmx.net       http://yi.org/peter-e/

  23. Re: Re: Getting configure to notice link-time vs run-time failures

    Patrick Welche <prlw1@newn.cam.ac.uk> — 2001-01-19T15:09:59Z

    On Fri, Jan 19, 2001 at 12:46:53AM +0100, Peter Eisentraut wrote:
> Tom Lane writes:
> 
> > Gene and I looked into this, and the cause of the misbehavior is this:
> > gcc on this installation is set to search /usr/local/lib (along with the
> > usual system library directories).  libz.so and libreadline.so are
> > indeed in /usr/local/lib, so configure's tests to see if they can be
> > linked against will succeed.  But he had LD_LIBRARY_PATH set to a list
> > that did *not* include /usr/local/lib, so actually firing up the
> > executable would fail.
> 
> You get what you pay for.  If you're running executables from configure
> you're asking for it.
> 
> This setup is a poor man's cross-compilation situation because the system
> you're compiling on is not identically configured to the system you're
> going to run on.  (Strictly speaking, the behaviour of a test program
> might even vary with different LD_LIBRARY_PATH settings.)
> 
> So
> 
> a)  PostgreSQL does not support cross-compilation (yet).  Too bad.
> 
> b)  We could get rid of all executition time checks in configure (to
>     remedy (a)).  This is one of my plans for the future.
> 
> c)  You could move the execution time checks up before the suspicious
>     library checks, but I'm afraid that this will only cure a particular
>     symptom and might introduce other problems.
> 
> I'd say, you're stuck.
> 
> -- 
> Peter Eisentraut      peter_e@gmx.net       http://yi.org/peter-e/
> 

Wouldn't a -Wl,-R/usr/local/lib have helped?

Cheers,

Patrick

  24. Re: Re: Getting configure to notice link-time vs run-time failures

    Tom Lane <tgl@sss.pgh.pa.us> — 2001-01-19T15:17:46Z

    Patrick Welche <prlw1@newn.cam.ac.uk> writes:
> Wouldn't a -Wl,-R/usr/local/lib have helped?

Well, yeah, but how would we know to do that?  The fact that gcc is
searching /usr/local/lib is completely unknown to configure.

			regards, tom lane

  25. Re: R-Tree implementation using GiST

    Bruce Momjian <pgman@candle.pha.pa.us> — 2001-01-24T03:32:52Z

    I have added the URL to the GIST SGML docs.

> Hi,
> 
> I've put R-Tree realization using GiST (yet another test of our changes in

> gist code )on my gist page http://www.sai.msu.su/~megera/postgres/gist/
                             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

> Also, I've put some GiST related papers for interested readers.
> The package( contrib-rtree_box_gist.tar.gz ) is built for 7.1.
> If you find it's interesting you may include it into contrib area for 7.1
> 
> from README.rtree_box_gist:
> 
> 
> 1. One interesting thing is that insertion time for built-in R-Tree is
>    about 8 times more than ones for GiST implementation of R-Tree !!!
> 2. Postmaster requires much more memory for built-in R-Tree
> 3. Search time depends on dataset. In our case we got:
>         +------------+-----------+--------------+
>         |Number boxes|R-tree, sec|R-tree using  |
>         |            |           |   GiST, sec  |
>         +------------+-----------+--------------+
>         |          10|      0.002|         0.002|
>         +------------+-----------+--------------+
>         |         100|      0.002|         0.002|
>         +------------+-----------+--------------+
>         |        1000|      0.002|         0.002|
>         +------------+-----------+--------------+
>         |       10000|      0.015|         0.025|
>         +------------+-----------+--------------+
>         |       20000|      0.029|         0.048|
>         +------------+-----------+--------------+
>         |       40000|      0.055|         0.092|
>         +------------+-----------+--------------+
>         |       80000|      0.113|         0.178|
>         +------------+-----------+--------------+
>         |      160000|      0.338|         0.337|
>         +------------+-----------+--------------+
>         |      320000|      0.674|         0.673|
>         +------------+-----------+--------------+
> 
> 
> 	Regards,
> 		Oleg
> _____________________________________________________________
> Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
> Sternberg Astronomical Institute, Moscow University (Russia)
> Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/
> phone: +007(095)939-16-83, +007(095)939-23-83
> 
> 


-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026