On Thu, Jun 2, 2016 at 12:35 PM, Andreas 'ads' Scherbaum
wrote:
> the TESTING file in src/bin/pg_upgrade talks about a "check.sh script", but
> this seems to be a binary (check) now.
Nope:
[rhaas pgsql]$ git grep -F check.sh
[rhaas pgsql]$
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.c
Hi,
the TESTING file in src/bin/pg_upgrade talks about a "check.sh script",
but this seems to be a binary (check) now.
Regards,
--
Andreas 'ads' Scherbaum
German PostgreSQL User Group
European PostgreSQL User Group - Board of Directors
Volunteer Regional Cont
Simon Riggs wrote on 29/12/15 05:31:
[...]
Thanks for testing.
Do you have any comments on performance testing?
Not really, because I didn't have an equivalent environment to compare. These
tests took exactly the same time as another one with Postgresql 9.3, with a
major different in the set
On 28 December 2015 at 22:56, Boriss Mejias wrote:
> Hi there,
>
> The following wiki page:
> https://wiki.postgresql.org/wiki/HowToBetaTest#How_to_Test
> suggests that I should send the following report to this mailing list.
>
Thanks for testing.
Do you have any comments on performance testing
Hi there,
The following wiki page:
https://wiki.postgresql.org/wiki/HowToBetaTest#How_to_Test
suggests that I should send the following report to this mailing list.
Name: Boriss Mejías (Tchorix)
Release: Postgresql 9.5 RC1
Test Type: Compatibility with Alfresco Community Edition 5.0.d
Test De
On 09/04/2015 09:30 PM, Simon Riggs wrote:
On 4 September 2015 at 13:45, Heikki Linnakangas wrote:
Another issue was with the new speculative insertions. Replaying a
speculative insertion record sets the tuple's CTID to point to itself, like
in a regular insertion. But in the original system,
On 4 September 2015 at 13:45, Heikki Linnakangas wrote:
> Another issue was with the new speculative insertions. Replaying a
> speculative insertion record sets the tuple's CTID to point to itself, like
> in a regular insertion. But in the original system, the CTID is set to a
> special speculat
I rerun my little testing tool that compares buffer page contents after
every modification, in master and in WAL replay. Previously discussed
here: http://www.postgresql.org/message-id/5357b582.7060...@vmware.com.
Here's an updated version of my original hack, for current git master.
(Michael p
On Mon, Dec 8, 2014 at 12:43:36PM -0500, Robert Haas wrote:
> On Sat, Dec 6, 2014 at 10:43 PM, Bruce Momjian wrote:
> > This causes creation DDL is checked if it is used in the regression
> > database, but what about ALTER and DROP? pg_dump doesn't issue those,
> > except in special cases like i
On Sat, Dec 6, 2014 at 10:43 PM, Bruce Momjian wrote:
> This causes creation DDL is checked if it is used in the regression
> database, but what about ALTER and DROP? pg_dump doesn't issue those,
> except in special cases like inheritance.
The proposed testing mechanism should cover any ALTER co
On 14/12/07 12:43, Bruce Momjian wrote:
> On Tue, Dec 2, 2014 at 03:13:07PM -0300, Alvaro Herrera wrote:
>> Robert Haas wrote:
>>> On Thu, Nov 27, 2014 at 11:43 PM, Ian Barwick wrote:
>>
A simple schedule to demonstrate this is available; execute from the
src/test/regress/ directory lik
On Tue, Dec 2, 2014 at 03:13:07PM -0300, Alvaro Herrera wrote:
> Robert Haas wrote:
> > On Thu, Nov 27, 2014 at 11:43 PM, Ian Barwick wrote:
>
> > > A simple schedule to demonstrate this is available; execute from the
> > > src/test/regress/ directory like this:
> > >
> > > ./pg_regress \
>
On Fri, Dec 5, 2014 at 04:10:12PM -0300, Alvaro Herrera wrote:
> Well, ALTER TABLE is special: you can give several subcommands, and each
> subcommand can be one of a rather long list of possible subcommands.
> Testing every combination would mean a combinatorial explosion, which
> would indeed be
Bruce Momjian wrote:
> On Fri, Dec 5, 2014 at 09:29:59AM -0300, Alvaro Herrera wrote:
> > Bruce Momjian wrote:
> > > On Fri, Nov 28, 2014 at 01:43:36PM +0900, Ian Barwick wrote:
> > > > Standard regression tests are helpful because patch authors include new
> > > > test
> > > > cases in the patch
On Fri, Dec 5, 2014 at 09:29:59AM -0300, Alvaro Herrera wrote:
> Bruce Momjian wrote:
> > On Fri, Nov 28, 2014 at 01:43:36PM +0900, Ian Barwick wrote:
> > > Standard regression tests are helpful because patch authors include new
> > > test
> > > cases in the patches that stress their new options
Bruce Momjian wrote:
> On Fri, Nov 28, 2014 at 01:43:36PM +0900, Ian Barwick wrote:
> > Standard regression tests are helpful because patch authors include new test
> > cases in the patches that stress their new options or commands. This new
> > test
> > framework needs to be something that inter
On Fri, Nov 28, 2014 at 01:43:36PM +0900, Ian Barwick wrote:
> Standard regression tests are helpful because patch authors include new test
> cases in the patches that stress their new options or commands. This new test
> framework needs to be something that internally runs the regression tests an
Robert Haas wrote:
> On Thu, Nov 27, 2014 at 11:43 PM, Ian Barwick wrote:
> > A simple schedule to demonstrate this is available; execute from the
> > src/test/regress/ directory like this:
> >
> > ./pg_regress \
> > --temp-install=./tmp_check \
> > --top-builddir=../../.. \
> >
On Thu, Nov 27, 2014 at 11:43 PM, Ian Barwick wrote:
> DDL deparsing is a feature that allows collection of DDL commands as they
> are
> executed in a server, in some flexible, complete, and fully-contained format
> that allows manipulation, storage, and transmission. This feature has
> several
>
DDL deparsing is a feature that allows collection of DDL commands as they are
executed in a server, in some flexible, complete, and fully-contained format
that allows manipulation, storage, and transmission. This feature has several
use cases; the two best known ones are DDL replication and DDL a
Hi all
I'm going to be contributing a fair bit of time to RLS for 2ndQuadrant,
courtesy of the EU AXLE project (http://axleproject.eu/).
I've been catching up on Kohei KaiGai's work and I've been really
impressed by what's already done and working. I'm currently reading the
patches, mailing list
Folks,
Wanted to give you the below testing emails from DHAVAL JAISWAL. He's
been testing 9.3's streaming-only cascading replication, and so far it
works as advertised. What he found in his tests was:
a) he could not remaster to a former replica which was behind the relica
he was trying to rema
On Tue, Jul 10, 2012 at 1:38 PM, Heikki Linnakangas <
heikki.linnakan...@enterprisedb.com> wrote:
> I think the ultimate question is, which ones of these should we include in
> core? We cannot drop the existing range_ops opclass, if only because that
> would break pg_upgrade. However, range_ops2 s
On 10.07.2012 02:33, Alexander Korotkov wrote:
Hackers,
I've tested various opclasses for ranges (including currently in-core one
and my patches). I've looked into scholar papers for which datasets they
are using for testing. The lists below show kinds of datasets used in
papers.
Great! That's
James Cloos wrote:
>create index mb_name_own_idx on mb ( lower(name), ownerid );
> WHERE lower(name) = lower('foo@bar') AND ownerid=7;
If you expect to be using an equality test on ownerid, you should
put that first in the index.
BTW, this is starting to sound more like something for
As a followup, I find that I can avoid the seq scan by adding an index
to that table as:
create index mb_name_own_idx on mb ( lower(name), ownerid );
and changing the query from using the idiom:
WHERE name ILIKE 'foo@bar' AND ownerid=7;
to using:
WHERE lower(name) = lower('foo@bar') AND
Updating pg_database to set datctype='C' did solve the speed issues with
the two largs dbs.
Presumably, since LC_CTYPE=en_US.UTF-8 was in the env when I ran pg_restore,
it overrode the ctype setting in the dump files.
Some of the slow selects do use ilike; even w/ datctype='C' the indices
are ski
On tis, 2012-06-19 at 09:33 -0400, Tom Lane wrote:
> Come to think of it, another possible factor is that LIKE can't use
> ordinary indexes on text if the locale isn't C.
But he reported that the plans are the same.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make c
Peter Eisentraut writes:
> On tis, 2012-06-19 at 02:38 -0400, Tom Lane wrote:
>> If James is testing text-comparison-heavy operations, it doesn't seem
>> shocking in the least. strcoll() in most non-C locales is a pig.
> Ah yes, of course, having lc_ctype != C also selects strcoll instead of
>
On tis, 2012-06-19 at 02:38 -0400, Tom Lane wrote:
> Peter Eisentraut writes:
> > On mån, 2012-06-18 at 17:57 -0400, James Cloos wrote:
> >> I presume that lc_ctype is the significant difference?
>
> > It certainly makes some difference, but it's a bit shocking that
> makes
> > things that much s
Peter Eisentraut writes:
> On mån, 2012-06-18 at 17:57 -0400, James Cloos wrote:
>> I presume that lc_ctype is the significant difference?
> It certainly makes some difference, but it's a bit shocking that makes
> things that much slower.
If James is testing text-comparison-heavy operations, it
On mån, 2012-06-18 at 17:57 -0400, James Cloos wrote:
> > "JB" == Josh Berkus writes:
>
> JB> Can you check the collations of the two databases? I'm wondering if 9.1
> JB> is in "C" collation and 9.2 is something else.
>
> Thanks!
>
> pg_dump -C tells me these two differences:
>
> -SET c
> "JB" == Josh Berkus writes:
JB> Can you check the collations of the two databases? I'm wondering if 9.1
JB> is in "C" collation and 9.2 is something else.
Thanks!
pg_dump -C tells me these two differences:
-SET client_encoding = 'SQL_ASCII';
+SET client_encoding = 'UTF8';
-CREATE DA
> PE> Compare the output of pg_config --configure from both installations.
>
> The only differences are 9.1 vs 9.2 in the paths.
Can you check the collations of the two databases? I'm wondering if 9.1
is in "C" collation and 9.2 is something else.
--
Josh Berkus
PostgreSQL Experts Inc.
http:
> "PE" == Peter Eisentraut writes:
PE> That depends on how you built it. Just being a beta by itself doesn't
PE> turn on any extra debugging.
OK. So either I misremembered or it was something no longer done.
PE> That depends on how you built it.
Its a Gentoo box; both were build from the
> "AF" == Andres Freund writes:
AF> Is it possible that you compiled with assertions enabled? That would
roughly
AF> fit that magnitude. SHOW debug_assertions; Should show you whether it was
AF> enabled.
Thanks, but SHOW debug_assertions reports off.
-JimC
--
James Cloos OpenPG
On sön, 2012-06-17 at 18:51 -0400, James Cloos wrote:
> I think I recall mention from a previous beta (but goog isn't helping
> me confirm) that there is some extra debugging or such enabled in the
> betas.
That depends on how you built it. Just being a beta by itself doesn't
turn on any extra de
Hi,
On Monday, June 18, 2012 12:51:51 AM James Cloos wrote:
> I'm giving 9.2-beta2 a test simulating a production workflow.
>
> Everything looks OK except the speed. Most (all?) queries take about
> five to six times as long as they do with 9.1.
>
> The configurations are essentially the same,
I'm giving 9.2-beta2 a test simulating a production workflow.
Everything looks OK except the speed. Most (all?) queries take about
five to six times as long as they do with 9.1.
The configurations are essentially the same, the query plans are the same.
A (hot) example, pulled semi-randomly from
Pavan Deolasee wrote:
> The numbers are not that bad, but definitely not as good as we saw
> on some other platforms.
Well, this machine is definitely designed to hold up under high
concurrency. As I understand it, each core is the memory manager
for two 4GB DIMMs, with two channels to them,
On Tue, Nov 22, 2011 at 4:40 AM, Kevin Grittner
wrote:
> Pavan Deolasee wrote:
>
>> It will be a great help if you could spare few minutes to also
>> test the patch to take out the frequently accessed PGPROC members
>> to a different array. We are seeing good improvements on HPUX IA
>> platform a
Pavan Deolasee wrote:
> It will be a great help if you could spare few minutes to also
> test the patch to take out the frequently accessed PGPROC members
> to a different array. We are seeing good improvements on HPUX IA
> platform and the AMD Opteron and it will be interesting to know
> what h
On Mon, Nov 21, 2011 at 11:01 PM, Kevin Grittner
wrote:
> Pavan Deolasee wrote:
>
>> It will be a great help if you could spare few minutes to also
>> test the patch to take out the frequently accessed PGPROC members
>> to a different array. We are seeing good improvements on HPUX IA
>> platform
Pavan Deolasee wrote:
> It will be a great help if you could spare few minutes to also
> test the patch to take out the frequently accessed PGPROC members
> to a different array. We are seeing good improvements on HPUX IA
> platform and the AMD Opteron and it will be interesting to know
> what h
On Mon, Nov 21, 2011 at 10:44 PM, Kevin Grittner
wrote:
> "Kevin Grittner" wrote:
>
>> I can run one more set of tests tonight before I have to give it
>> back to the guy who's putting it into production. It sounds like
>> a set like the above except with synchronous_commit = off might be
>> des
"Kevin Grittner" wrote:
> I can run one more set of tests tonight before I have to give it
> back to the guy who's putting it into production. It sounds like
> a set like the above except with synchronous_commit = off might be
> desirable?
OK, that's what I did. This gave me my best numbers
Robert Haas wrote:
> I was actually thinking it would be interesting to oprofile the
> read-only test; see if we can figure out where those slowdowns are
> coming from.
CPU: Intel Core/i7, speed 2262 MHz (estimated)
Counted CPU_CLK_UNHALTED events (Clock cycles when not halted) with
a unit mas
Robert Haas wrote:
> Hmm. There's obviously something that's different in your
> environment or configuration from what I tested, but I don't know
> what it is. The fact that your scale factor is larger than
> shared_buffers might matter; or Intel vs. AMD. Or maybe you're
> running with synchr
On Saturday, November 19, 2011 12:18:07 AM Kevin Grittner wrote:
> Andres Freund wrote:
> > I think opannotate -a -s produces output with instructions/code
> > intermingled.
>
> Thanks. I'll check out perf later (thanks for the tips!), but for
> now, here's the function which was at the top of m
On Fri, Nov 18, 2011 at 6:46 PM, Kevin Grittner
wrote:
>>> tps = 21946.961196 (including connections establishing)
>>> tps = 22911.873227 (including connections establishing)
>>>
>>> For write transactions, that seems pretty respectable.
>>
>> Very. What do you get without the patch?
>
> [quick r
Robert Haas wrote:
> Hmm. That looks a lot like a profile with no lock contention at
> all. Since I see XLogInsert in there, I assume this must be a
> pgbench write test on unlogged tables? How close am I?
Not unless pgbench on HEAD does that by default. Here are the
relevant statements:
On Fri, Nov 18, 2011 at 2:05 PM, Kevin Grittner
wrote:
> Robert Haas wrote:
>> Any chance you can run oprofile (on either branch, don't really
>> care) against the 32 client test and post the results?
>
> [ oprofile results ]
Hmm. That looks a lot like a profile with no lock contention at all.
Andres Freund wrote:
> I think opannotate -a -s produces output with instructions/code
> intermingled.
Thanks. I'll check out perf later (thanks for the tips!), but for
now, here's the function which was at the top of my oprofile
results, annotated with those options. I'm afraid it's a bit
i
On Friday, November 18, 2011 11:12:02 PM Andres Freund wrote:
> On Friday, November 18, 2011 09:16:01 PM Kevin Grittner wrote:
> > Andres Freund wrote:
> > > When doing line-level profiles I would suggest looking at the
> > > instructions.
> >
> > What's the best way to do that?
>
> I think opan
On Friday, November 18, 2011 09:16:01 PM Kevin Grittner wrote:
> Andres Freund wrote:
> > When doing line-level profiles I would suggest looking at the
> > instructions.
> What's the best way to do that?
I think opannotate -a -s produces output with instructions/code intermingled.
> > I don't thi
Andres Freund wrote:
> When doing line-level profiles I would suggest looking at the
> instructions.
What's the best way to do that?
> I don't think cache line contention is the most likely candidate
> here. Simple cache-misses seem far more likely. In combination
> with pipeline stalls...
On Friday, November 18, 2011 08:36:59 PM Kevin Grittner wrote:
> "Kevin Grittner" wrote:
> > samples %image name symbol name
> > 4954633.6718 postgreshash_search_with_hash_value
>
> When lines like these show up in the annotated version, I'm
> impressed that we're still
Robert Haas wrote:
>> I think so. My take was that it was showing 32 of 64 *threads*
>> active -- the hyperthreading funkiness. Is there something in
>> particular you'd like me to check?
>
> Not really, just don't understand the number.
I'm having trouble resolving the vmstat numbers I got
"Kevin Grittner" wrote:
> samples %image name symbol name
> 4954633.6718 postgreshash_search_with_hash_value
When lines like these show up in the annotated version, I'm
impressed that we're still finding gains as big as we are:
44613 0.3306 :if (segp == NU
"anara...@anarazel.de" wrote:
> Kevin Grittner schrieb:
>>samples %image name symbol name
>>9333944.9651 postgresAllocSetAlloc
>>8484764.5134 postgresbase_yyparse
>>7195153.8274 postgresSearchCatCache
> That profile looks like you ran pgben
Kevin Grittner schrieb:
>Robert Haas wrote:
>
>> Any chance you can run oprofile (on either branch, don't really
>> care) against the 32 client test and post the results?
>
>Besides the other changes we discussed, I boosted scale to 150 and
>ran at READ COMMITTED isolation level (because all
Robert Haas wrote:
> Any chance you can run oprofile (on either branch, don't really
> care) against the 32 client test and post the results?
Besides the other changes we discussed, I boosted scale to 150 and
ran at READ COMMITTED isolation level (because all threads promptly
crashed and burne
Robert Haas wrote:
> Yeah, I'd just drop -S.
Easily done.
> Make sure to use -c N -j N with pgbench, or you'll probably not be
> able to saturate it.
Yeah, that's part of the script I copied from you.
> I've also had good luck with wal_writer_delay=20ms, although if
> you have synchronou
On Fri, Nov 18, 2011 at 12:45 PM, Kevin Grittner
wrote:
> OK. Sorry for misunderstanding that. I haven't gotten around to a
> deep reading of the patch yet. :-( I based this on the test script
> you posted here (with slight modifications for my preferred
> directory structures):
>
> http://arc
Robert Haas wrote:
> Kevin Grittner wrote:
>>> Then again, is this a regular pgbench test or is this
>>> SELECT-only?
>>
>> SELECT-only
>
> Ah, OK. I would not expect flexlocks to help with that; Pavan's
> patch might, though.
OK. Sorry for misunderstanding that. I haven't gotten around t
On Fri, Nov 18, 2011 at 12:03 PM, Kevin Grittner
wrote:
>> Then again, is this a regular pgbench test or is this SELECT-only?
>
> SELECT-only
Ah, OK. I would not expect flexlocks to help with that; Pavan's patch
might, though.
>> Can you by any chance check top or vmstat during the 32-client
>>
"Kevin Grittner" wrote:
> We have a 32-core Intel box (4 x X7560 @ 2.27GHz) with 256 GB
> RAM.
In case anyone cares, this is the same box for which I posted STREAM
test results a while back. The PostgreSQL tests seem to peak on
this 32-core box at 64 clients, while the STREAM test of raw RAM
Robert Haas wrote:
> Then again, is this a regular pgbench test or is this SELECT-only?
SELECT-only
> Can you by any chance check top or vmstat during the 32-client
> test and see what percentage you have of user time/system
> time/idle time?
You didn't say whether you wanted master or fle
On Fri, Nov 18, 2011 at 11:26 AM, Kevin Grittner
wrote:
> Robert Haas wrote:
>> Nate Boley's AMD 6128 box (which has 32 cores) and an HP Integrity
>> server (also with 32 cores).
>
>> [clear improvement with flexlock patch]
>
> Hmm. We have a 32-core Intel box (4 x X7560 @ 2.27GHz) with 256 GB
>
Robert Haas wrote:
> Nate Boley's AMD 6128 box (which has 32 cores) and an HP Integrity
> server (also with 32 cores).
> [clear improvement with flexlock patch]
Hmm. We have a 32-core Intel box (4 x X7560 @ 2.27GHz) with 256 GB
RAM. It's about a week from going into production, at which p
I'm working on fixing the stale-toast-pointer problem discussed in
http://archives.postgresql.org/message-id/2348.1319591...@sss.pgh.pa.us
In that thread, it was pointed out that it's unsafe to fetch a toasted
value unless we are advertising a MyProc->xmin that's old enough to
prevent removal of t
2011/7/5 Robert Haas :
> On Wed, Jun 15, 2011 at 7:43 AM, Pavel Stehule
> wrote:
>> Hello Heikki,
>>
>> probably I found a bug in patch:
>>
>> CREATE FUNCTION fx(i integer) RETURNS integer
>> LANGUAGE plpgsql
>> AS $$begin raise notice '>>%<<', i; return i; end;$$;
>>
>> CREATE FUNCTION fx1
On Wed, Jun 15, 2011 at 7:43 AM, Pavel Stehule wrote:
> Hello Heikki,
>
> probably I found a bug in patch:
>
> CREATE FUNCTION fx(i integer) RETURNS integer
> LANGUAGE plpgsql
> AS $$begin raise notice '>>%<<', i; return i; end;$$;
>
> CREATE FUNCTION fx1(integer) RETURNS text
> LANGUAGE
Hello Heikki,
probably I found a bug in patch:
CREATE FUNCTION fx(i integer) RETURNS integer
LANGUAGE plpgsql
AS $$begin raise notice '>>%<<', i; return i; end;$$;
CREATE FUNCTION fx1(integer) RETURNS text
LANGUAGE sql
AS $_$ select case $1 when 1 then 'A' else 'B' end$_$;
CREAT
da...@kineticode.com ("David E. Wheeler") writes:
> You should blog this.
He just did, using the SMTP protocol...
--
select 'cbbrowne' || '@' || 'acm.org';
http://linuxdatabases.info/info/postgresql.html
Where do you want to Tell Microsoft To Go Today?
--
Sent via pgsql-hackers mailing list (pg
"David E. Wheeler" writes:
> You should blog this.
He just did, didn't he? :)
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://
"David E. Wheeler" writes:
> You should blog this.
[ shrug... ] I don't own a blog, and if I did the entries in it would
not be included in the pgsql archives, which is where material like this
probably ought to be.
regards, tom lane
--
Sent via pgsql-hackers mailing l
You should blog this.
David
On Mar 2, 2011, at 11:58 AM, Tom Lane wrote:
> It occurred to me that it might be a good idea to describe how
> I've been testing extension upgrade scripts. So:
>
> 1. Install the 9.0 version of the module in an empty 9.0 database.
> pg_dump this database.
>
> 2. L
It occurred to me that it might be a good idea to describe how
I've been testing extension upgrade scripts. So:
1. Install the 9.0 version of the module in an empty 9.0 database.
pg_dump this database.
2. Load the pg_dump script into an empty 9.1 database, with the
underlying shared library (if
On tis, 2010-07-13 at 20:28 -0500, Chris wrote:
> So if I have to explicitly set the python interpretor, how would you
> ever have a plpython2u and plpython3u function in the same DB
> (regardless of the fact that they can't run in the same session)? The
> manual implies you could have them both i
>
>
> You'd have to build the two plpython.so's in separate compile operations.
>
>regards, tom lane
>
I hadn't thought of that. Tried it and it does work. Thanks.
--
Chris Spotts
rfu...@gmail.com
Chris writes:
> So if I have to explicitly set the python interpretor, how would you ever
> have a plpython2u and plpython3u function in the same DB (regardless of the
> fact that they can't run in the same session)?
You'd have to build the two plpython.so's in separate compile operations.
So if I have to explicitly set the python interpretor, how would you ever
have a plpython2u and plpython3u function in the same DB (regardless of the
fact that they can't run in the same session)? The manual implies you could
have them both installed since it says that there's a per session
limita
On tis, 2010-07-13 at 15:38 -0500, Chris wrote:
> I'm testing beta 3 and ran across a PL/Python3u bug again.
> This time it won't let me install it at all.
> Kubuntu 10.04
>
> ./configure --with-pgport=5433 --with-python --with-ossp-uuid
> --with-libxml
> --with-libxslt --with-perl --prefix=/usr/l
I'm testing beta 3 and ran across a PL/Python3u bug again.
This time it won't let me install it at all.
Kubuntu 10.04
./configure --with-pgport=5433 --with-python --with-ossp-uuid --with-libxml
--with-libxslt --with-perl --prefix=/usr/local/pgsqlb3
make
make check
sudo make install
All work fine.
Peter Eisentraut writes:
> Why are we using RTLD_GLOBAL?
Some guy named Eisentraut wanted it for plpython:
http://archives.postgresql.org/pgsql-hackers/2001-05/msg00563.php
http://archives.postgresql.org/pgsql-committers/2001-05/msg00283.php
Possibly that no longer applies, though. In general i
On fre, 2010-06-25 at 18:57 -0400, Peter Eisentraut wrote:
> On fre, 2010-06-25 at 23:44 +0200, Andres Freund wrote:
> > Has anybody actually researched if it is safe to run python2 and
> > python3 in the same address space?
>
> You can't run plpython2 and plpython3 in the same session, because th
Tom Lane wrote:
> Bruce Momjian writes:
> > Josh Berkus wrote:
> >>> You could argue it either way. The number of beta testers with
> >>> plpython3 installations is probably very small, so I'm kinda leaning to
> >>> just changing the code without a catversion bump. OTOH, if we want to
> >>> enco
Bruce Momjian writes:
> Josh Berkus wrote:
>>> You could argue it either way. The number of beta testers with
>>> plpython3 installations is probably very small, so I'm kinda leaning to
>>> just changing the code without a catversion bump. OTOH, if we want to
>>> encourage testing of pg_upgrade
Josh Berkus wrote:
>
> > You could argue it either way. The number of beta testers with
> > plpython3 installations is probably very small, so I'm kinda leaning to
> > just changing the code without a catversion bump. OTOH, if we want to
> > encourage testing of pg_upgrade ...
>
> FWIW, the las
On Fri, Jun 25, 2010 at 2:49 PM, Peter Eisentraut wrote:
> On fre, 2010-06-25 at 10:17 -0400, Tom Lane wrote:
>> Peter Eisentraut writes:
>> > The problem is apparently that when CREATE LANGUAGE creates a language
>> > from a pg_pltemplate entry, it creates the proname from the tmplhandler
>> > n
On fre, 2010-06-25 at 23:44 +0200, Andres Freund wrote:
> Has anybody actually researched if it is safe to run python2 and
> python3 in the same address space?
You can't run plpython2 and plpython3 in the same session, because the
libraries are loaded with dlopen(RTLD_GLOBAL) (with RTLD_LOCAL it w
On Wednesday 23 June 2010 16:30:54 Tom Lane wrote:
> Robert Haas writes:
> > I can reproduce this, here. The problem seems to be that plpython
> > only build either plpython2.so or plython3.so, but both languages
> > expect a call handler called plython_call_handler. So once we load
> > the shar
> You could argue it either way. The number of beta testers with
> plpython3 installations is probably very small, so I'm kinda leaning to
> just changing the code without a catversion bump. OTOH, if we want to
> encourage testing of pg_upgrade ...
FWIW, the last bump has led to a lot of testin
Peter Eisentraut writes:
> On fre, 2010-06-25 at 10:17 -0400, Tom Lane wrote:
>> The fix ought to be to change the function nmes used by plpython3 ...
> Right. What shall we do about the catversion?
You could argue it either way. The number of beta testers with
plpython3 installations is proba
On fre, 2010-06-25 at 10:17 -0400, Tom Lane wrote:
> Peter Eisentraut writes:
> > The problem is apparently that when CREATE LANGUAGE creates a language
> > from a pg_pltemplate entry, it creates the proname from the tmplhandler
> > name, and if it finds a fitting proname entry already, it used th
Peter Eisentraut writes:
> The problem is apparently that when CREATE LANGUAGE creates a language
> from a pg_pltemplate entry, it creates the proname from the tmplhandler
> name, and if it finds a fitting proname entry already, it used that one.
> So when you create plpython2 first and plpython3
On ons, 2010-06-23 at 07:17 -0400, Robert Haas wrote:
> I can reproduce this, here. The problem seems to be that plpython
> only build either plpython2.so or plython3.so, but both languages
> expect a call handler called plython_call_handler. So once we load
> the shared library for one language,
On Wed, Jun 23, 2010 at 10:49 AM, Robert Haas wrote:
> On Wed, Jun 23, 2010 at 10:30 AM, Tom Lane wrote:
>> Robert Haas writes:
>>> I can reproduce this, here. The problem seems to be that plpython
>>> only build either plpython2.so or plython3.so, but both languages
>>> expect a call handler c
On Wed, Jun 23, 2010 at 10:30 AM, Tom Lane wrote:
> Robert Haas writes:
>> I can reproduce this, here. The problem seems to be that plpython
>> only build either plpython2.so or plython3.so, but both languages
>> expect a call handler called plython_call_handler. So once we load
>> the shared l
1 - 100 of 499 matches
Mail list logo
