Martijn van Oosterhout wrote:
> None of this applies to PostgreSQL because we open the modules
> directly, and don't rely on the linker loader.
Ah, right. I forgot the context was the server, not one of the
utilities...
Sorry for the waste of bandwidth...
--
Kevin Brown
On Sat, Nov 12, 2005 at 10:46:33PM -0800, Kevin Brown wrote:
> Hmm...but isn't the version number also something that can be stored
> in the shared library itself during link time (e.g., via the -soname
> option to the linker)? The manpage for ld under Linux implies that
> this will cause the exec
Tom Lane wrote:
> On the other hand, it'd be relatively easy for clueless lusers to
> defeat; I can readily imagine someone copying foo.so.8.2 to foo.so.8.3
> when the backend complained that it couldn't find the latter. So
> maybe it's not what we want.
Hmm...but isn't the version number also so
Martijn van Oosterhout writes:
>> I was hoping to avoid forcing source-code changes, but something like
>> that might be the best solution. Anyone think it's unreasonable?
> Alternativly, you could make it optional for a release (print warning
> that magic block wasn't found). Next release requi
On Sat, Nov 12, 2005 at 12:44:23PM -0500, Tom Lane wrote:
> Martijn van Oosterhout writes:
> > If we don't like imposing link time constraints, we could require
> > people to include:
>
> > #ifdef PG_MAGIC_BLOCK
> > PG_MAGIC_BLOCK;
> > #endif
>
> I was hoping to avoid forcing source-code changes
Martijn van Oosterhout writes:
> If we don't like imposing link time constraints, we could require
> people to include:
> #ifdef PG_MAGIC_BLOCK
> PG_MAGIC_BLOCK;
> #endif
I was hoping to avoid forcing source-code changes, but something like
that might be the best solution. Anyone think it's unr
On Sat, Nov 12, 2005 at 12:03:00PM -0500, Tom Lane wrote:
> That would be attractive if we could get it to happen without the
> assumption that the library uses PG_FUNCTION_INFO_V1 ... but if it still
> needs that assumption, it doesn't seem like much of an improvement.
> It's not always easy for p
Martijn van Oosterhout writes:
> On Sat, Nov 12, 2005 at 11:18:51AM -0500, Tom Lane wrote:
>> How so? All we care about is being able to (1) compare for equality,
>> and (2) print out something useful in error messages. I claim that
>> PG_VERSION does #1 equally well and #2 better.
> I was thin
On Sat, Nov 12, 2005 at 11:18:51AM -0500, Tom Lane wrote:
> Martijn van Oosterhout writes:
> > Sure, CATALOG_VERSION isn't that useful, but it's the only thing in the
> > header files that gives any kind of indication what version you're
> > compiling against. PG_VERSION is a string, which diminis
Martijn van Oosterhout writes:
> Sure, CATALOG_VERSION isn't that useful, but it's the only thing in the
> header files that gives any kind of indication what version you're
> compiling against. PG_VERSION is a string, which diminishes its
> usefulness considerably.
How so? All we care about is
On Sat, Nov 12, 2005 at 10:47:35AM -0500, Tom Lane wrote:
> Martijn van Oosterhout writes:
> > I would be in favour if storing the CATALOG_VERSION in the pg_finfo
> > struct and rejecting anything that doesn't match.
>
> Not sure that CATALOG_VERSION is an amazingly useful thing to use.
> I think
I thought of an alternative approach to the library version problem:
what about taking a leaf from the usual shared library versioning
approach, ie, put the version number into the library file name?
So instead of loading, say, "plpgsql.so" we'd insist on loading
"plpgsql.so.8.2".
This would avoid
Martijn van Oosterhout writes:
> So the idea is to force failure when it would otherwise succeed, not
> just for the pretty error messages but for stability of the system.
Exactly. Peter's right that we'd not always get a "nice" error message
--- but it's not hard to figure out "unresolved symbo
On Sat, Nov 12, 2005 at 12:28:48PM +0100, Peter Eisentraut wrote:
> I think this would rarely work in practice. For example, during the
> elog->ereport transition, any module compiled against the wrong server
> would immediately get an "unresolved symbol: elog/ereport" before you
> can run your
Gregory Maxwell wrote:
> So it turned out that he didn't... Is this a sign that we need to
> include a versioning symbol in SOs so we can give a nice clear error
> message "module foo compiled for PostgreSQL 8.0.2 this is PostgreSQL
> 8.1."
I think this would rarely work in practice. For example,
I've also modified the Makefile. I removed the special .sql.in : .sql implicit
rule and re-organized the Makefile. I didn't commit as it was after 12:00pm
when I finished...
I'll send you what I did when I return home. If you just replaced the $libdir
with $$libdir, then a merge will be easy.
I fixed path in pg_sphere (and done some more clean up).
BTW, I usially install contrib modules before restoring database (of course, it
need to dump db without content of modules)...
--
Teodor Sigaev E-mail: [EMAIL PROTECTED]
On Wed, 09 Nov 2005 10:42:00 -0500
Tom Lane <[EMAIL PROTECTED]> wrote:
>
> If pg_sphere is supplying a setup procedure that gets this wrong,
> yell at them.
I'll just go fix it, now that I know what the right way is ;-)
Thanks,
Rob
---(end of broadcast)-
On Wed, 09 Nov 2005 09:56:51 -0500
Andrew Dunstan <[EMAIL PROTECTED]> wrote:
>
> Why use an absolute path? Why not just give the name of the .so and let
> postgres find it in $libdir (i.e. sed -e 's,/usr/local/pgsql.*/lib/,,'
> on your dump) ?
'cause I didn't know I could? I'll go and fix the
On Wed, Nov 09, 2005 at 10:57:25AM -0500, Tom Lane wrote:
> There are cases where it would work, and other cases where it wouldn't.
> Given the pain involved in debugging when it's wrong, maybe we should
> just endeavor to forbid loading of all wrong-version modules.
>
> I'm not sure that there's
Gregory Maxwell <[EMAIL PROTECTED]> writes:
> On 11/8/05, Tom Lane <[EMAIL PROTECTED]> wrote:
>> Does look a bit suspicious ... Robert, are you *sure* you've got the
>> right version of pgsphere linked in?
> So it turned out that he didn't... Is this a sign that we need to
> include a versioning s
Robert Creager <[EMAIL PROTECTED]> writes:
> CREATE FUNCTION sbox_in(cstring) RETURNS sbox
> AS '/usr/local/pgsql802/lib/pg_sphere', 'spherebox_in'
> LANGUAGE c IMMUTABLE STRICT;
> Now if I can just figure out how to get this egg off my face...
You'd be a lot better off to define all your
On 11/8/05, Tom Lane <[EMAIL PROTECTED]> wrote:
> Teodor Sigaev <[EMAIL PROTECTED]> writes:
> > Layout of GIST_SPLITVEC struct has been changed from 8.0, I'm afraid that
> > old
> > .so is used. spl_(right|left)valid fields was added to GIST_SPLITVEC.
>
> Does look a bit suspicious ... Robert, ar
Robert Creager wrote:
Yup. You're right. So, what is happening here? It will be kind of hard to do
a live dump/restore on 1 machine if I cannot have two versions running. Is
something not set up correctly on my machine, or in the build (pg_sphere or
postgresql) that is preventing two co
When grilled further on (Wed, 09 Nov 2005 10:54:12 +0300),
Teodor Sigaev <[EMAIL PROTECTED]> confessed:
> > So, I'm as sure as I can be right now. How can I check the .so files
> > installed
> > by the build? Do they reference an absolute path for their dependent .so
> > files
> > (postgres),
So, I'm as sure as I can be right now. How can I check the .so files installed
by the build? Do they reference an absolute path for their dependent .so files
(postgres), or will they use ld.so.conf, which might then explain the problem.
My ld.so.conf still points to the 8.0.2 version, as I've n
works fine
contrib_regression=# select count(*) from test_data ;
count
---
250
(1 row)
contrib_regression=# create index test_data_index on test_data using gist( loc
);
CREATE INDEX
I've attached a small dump file that when I create an index on the table, it
fails. It works on 2
When grilled further on (Tue, 08 Nov 2005 11:12:04 -0500),
Tom Lane <[EMAIL PROTECTED]> confessed:
> Teodor Sigaev <[EMAIL PROTECTED]> writes:
> > Layout of GIST_SPLITVEC struct has been changed from 8.0, I'm afraid that
> > old
> > .so is used. spl_(right|left)valid fields was added to GIST_SPL
On Tue, 08 Nov 2005 11:12:04 -0500
Tom Lane <[EMAIL PROTECTED]> wrote:
> Teodor Sigaev <[EMAIL PROTECTED]> writes:
> > Layout of GIST_SPLITVEC struct has been changed from 8.0, I'm afraid that
> > old .so is used. spl_(right|left)valid fields was added to GIST_SPLITVEC.
>
> Does look a bit suspi
Teodor Sigaev <[EMAIL PROTECTED]> writes:
> Layout of GIST_SPLITVEC struct has been changed from 8.0, I'm afraid that old
> .so is used. spl_(right|left)valid fields was added to GIST_SPLITVEC.
Does look a bit suspicious ... Robert, are you *sure* you've got the
right version of pgsphere linked i
Tom Lane wrote:
Robert Creager <[EMAIL PROTECTED]> writes:
v->spl_right is address 0xbp - uninitialized?
The whole struct looks pretty uninitialized, which immediately makes me
wonder whether gdb has picked up a wrong value for "v". Try going down
to a lower stack frame and seeing if you
Robert Creager <[EMAIL PROTECTED]> writes:
> Is there any way I can do a without a
> reconfigure/make/install of postgresql? The db is running on port
> 5433, not the default of 5432.
Sure, just "export PGPORT=5433" before "make installcheck". Doubt it
will prove much, though, because the reg
When grilled further on (Tue, 08 Nov 2005 09:20:13 -0500),
Tom Lane <[EMAIL PROTECTED]> confessed:
> Robert Creager <[EMAIL PROTECTED]> writes:
> > v->spl_right is address 0xbp - uninitialized?
>
> The whole struct looks pretty uninitialized, which immediately makes me
> wonder whether gdb has pi
Robert Creager wrote:
Yes I did. Just did it again to make sure. Is there any way I can do a without a reconfigure/make/install of postgresql? The db is running
on port 5433, not the default of 5432.
export PGPORT=5433
If this is a PGSphere problem, should this conversation be continued
Robert Creager <[EMAIL PROTECTED]> writes:
> v->spl_right is address 0xbp - uninitialized?
The whole struct looks pretty uninitialized, which immediately makes me
wonder whether gdb has picked up a wrong value for "v". Try going down
to a lower stack frame and seeing if you can access the struct
When grilled further on (Tue, 08 Nov 2005 15:13:32 +0300),
Teodor Sigaev <[EMAIL PROTECTED]> confessed:
> Hmm, did you recompile pg_sphere module for 8.1?
Yes I did. Just did it again to make sure. Is there any way I can do a without a reconfigure/make/install of postgresql? The db is
runnin
Hmm, did you recompile pg_sphere module for 8.1?
Robert Creager wrote:
When grilled further on (Mon, 7 Nov 2005 22:25:17 -0700),
Robert Creager <[EMAIL PROTECTED]> confessed:
Sorry, I'll just trickle out the information.
tassiv=# \d catalog_ra_decl_index
Index "public.catalog_ra_decl_index"
When grilled further on (Mon, 7 Nov 2005 22:25:17 -0700),
Robert Creager <[EMAIL PROTECTED]> confessed:
Sorry, I'll just trickle out the information.
tassiv=# \d catalog_ra_decl_index
Index "public.catalog_ra_decl_index"
Column | Type
+---
loc| spherekey
gist, for tab
When grilled further on (Mon, 7 Nov 2005 08:07:14 -0700),
Robert Creager <[EMAIL PROTECTED]> confessed:
I'm currently attached to the dead (dying) process. spl_nright seems pretty
large...
(gdb) print v->spl_nright
$3 = 138311580
Program received signal SIGSEGV, Segmentation fault.
0x08082057
When grilled further on (Sun, 6 Nov 2005 20:00:38 -0700),
Robert Creager <[EMAIL PROTECTED]> confessed:
Didn't set the core big enough (1Mb). It's now at 50Mb.
I am using PGSphere, which should be the only gist indexes in use.
gdb /usr/local/pgsql810/bin/postgres core.28053
...
warning: core
When grilled further on (Sun, 06 Nov 2005 18:52:40 -0500),
Andrew Dunstan <[EMAIL PROTECTED]> confessed:
>
> Which version is first in your path, 8.0 or 8.1? If 8.0, do you get a
> different result from the 8.1 binaries?
>
8.0 was first. I've specified the correct full path now for the execut
Which version is first in your path, 8.0 or 8.1? If 8.0, do you get a
different result from the 8.1 binaries?
cheers
andrew
Robert Creager wrote:
Hey all,
I was doing a test run of a live dump from 8.0.2 to 8.1.0, and 8.1.0 took a
segmentation violation 1 hour into the operation. My plan
Hey all,
I was doing a test run of a live dump from 8.0.2 to 8.1.0, and 8.1.0 took a
segmentation violation 1 hour into the operation. My plan is to re-do the
dump/restore, and if it fails again, to re-compile with debug and cassert, and
try to get a core.
The command line was (8.1.0 is on port
43 matches
Mail list logo
