Skip site navigation (1) Skip section navigation (2)

Re: revised hstore patch

From: Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: revised hstore patch
Date: 2009-07-22 00:44:58
Message-ID: 87prbtmtpx.fsf@news-spur.riddles.org.uk (view raw or flat)
Thread:
Lists: pgsql-hackers
>>>>> "Tom" == Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

 >> (b) many of the old names are significant collision risks.

 Tom> What collision risks?  PG does not allow loadable libraries to
 Tom> export their symbols, so I don't see the problem.  I recommend
 Tom> just keeping those things named as they were.

You've never tested this, I can tell.

I specifically checked this point, back when working on the original
proposal (and when debugging the uuid code on freebsd, where uuid-ossp
crashes due to a symbol collision). If a loaded module compiled from
multiple source files defines some symbol, and another similar loaded
module tries to define the same symbol, then whichever one gets loaded
second will end up referring to the one from the first, obviously
causing hilarity to ensue.

I have a test case that demonstrates this and everything:

% bin/psql -c 'select foo()' postgres
NOTICE:  mod1a foo() called
NOTICE:  mod1b bar() called
 foo 
-----
 
(1 row)

% bin/psql -c 'select baz()' postgres
NOTICE:  mod2a baz() called
NOTICE:  mod2b bar() called
 baz 
-----
 
(1 row)

% bin/psql -c 'select baz(),foo()' postgres
NOTICE:  mod2a baz() called
NOTICE:  mod2b bar() called
NOTICE:  mod1a foo() called
NOTICE:  mod2b bar() called
 baz | foo 
-----+-----
     | 
(1 row)

% bin/psql -c 'select foo(),baz()' postgres
NOTICE:  mod1a foo() called
NOTICE:  mod1b bar() called
NOTICE:  mod2a baz() called
NOTICE:  mod1b bar() called
 foo | baz 
-----+-----
     | 
(1 row)

Notice that in the third case, foo() called the bar() function in mod2b,
not the one in mod1b which it called in the first case. All modules are
compiled with pgxs and no special options.

 >> Certainly when developing this I had _SIGNIFICANT_ encouragement, some
 >> of it from YOU, for increasing the limit.

 Tom> Yes, but that was before the interest in in-place upgrade went up.
 Tom> This patch is the first place where we have to decide whether we meant
 Tom> it when we said we were going to pay more attention to that.

 >> I'm prepared to give slightly more consideration to option #3: make
 >> the new code read the old format as well as the new one.

 Tom> If you think you can make that work, it would solve the problem.

OK. Should I produce an additional patch, or re-do the original one?

-- 
Andrew.

In response to

pgsql-hackers by date

Next:From: Andrew GierthDate: 2009-07-22 00:51:10
Subject: Re: revised hstore patch
Previous:From: Tom LaneDate: 2009-07-22 00:29:48
Subject: Re: Patch for contains/overlap of polygons

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group