Re: [HACKERS] TESTING in src/bin/pg_upgrade has incorrect documentation

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:

[HACKERS] TESTING in src/bin/pg_upgrade has incorrect documentation

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

Re: [HACKERS] Testing Postgresql 9.5 RC1 with Alfresco 5.0.d

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

[HACKERS] Testing Postgresql 9.5 RC1 with Alfresco 5.0.d

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

Re: [HACKERS] Testing Postgresql 9.5 RC1 with Alfresco 5.0.d

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

Re: [HACKERS] Testing WAL replay by comparing before and after images again

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

Re: [HACKERS] Testing WAL replay by comparing before and after images again

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

[HACKERS] Testing WAL replay by comparing before and after images again

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

Re: [HACKERS] Testing DDL deparsing support

On Mon, Dec 8, 2014 at 12:43:36PM -0500, Robert Haas wrote: On Sat, Dec 6, 2014 at 10:43 PM, Bruce Momjian br...@momjian.us 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

Re: [HACKERS] Testing DDL deparsing support

On Sat, Dec 6, 2014 at 10:43 PM, Bruce Momjian br...@momjian.us 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

Re: [HACKERS] Testing DDL deparsing support

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 i...@2ndquadrant.com wrote: A simple schedule to demonstrate this is available; execute from the src/test/regress/

Re: [HACKERS] Testing DDL deparsing support

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 i...@2ndquadrant.com wrote: A simple schedule to demonstrate this is available; execute from the src/test/regress/ directory like this: ./pg_regress

Re: [HACKERS] Testing DDL deparsing support

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 and

Re: [HACKERS] Testing DDL deparsing support

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 internally

Re: [HACKERS] Testing DDL deparsing support

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 or

Re: [HACKERS] Testing DDL deparsing support

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 patches that stress

Re: [HACKERS] Testing DDL deparsing support

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

Re: [HACKERS] Testing DDL deparsing support

On Thu, Nov 27, 2014 at 11:43 PM, Ian Barwick i...@2ndquadrant.com 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

Re: [HACKERS] Testing DDL deparsing support

Robert Haas wrote: On Thu, Nov 27, 2014 at 11:43 PM, Ian Barwick i...@2ndquadrant.com 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=../../..

[HACKERS] Testing DDL deparsing support

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

[HACKERS] Testing RLS with SECURITY DEFINER functions returning refcursors

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

[HACKERS] Testing Cascading Replication

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

Re: [HACKERS] Testing of various opclasses for ranges

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!

Re: [HACKERS] Testing of various opclasses for ranges

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 seems

Re: [HACKERS] Testing 9.2 in ~production environment

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

Re: [HACKERS] Testing 9.2 in ~production environment

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')

Re: [HACKERS] Testing 9.2 in ~production environment

James Cloos cl...@jhcloos.com 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

Re: [HACKERS] Testing 9.2 in ~production environment

On mån, 2012-06-18 at 17:57 -0400, James Cloos wrote: JB == Josh Berkus j...@agliodbs.com 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

Re: [HACKERS] Testing 9.2 in ~production environment

Peter Eisentraut pete...@gmx.net 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

Re: [HACKERS] Testing 9.2 in ~production environment

On tis, 2012-06-19 at 02:38 -0400, Tom Lane wrote: Peter Eisentraut pete...@gmx.net 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

Re: [HACKERS] Testing 9.2 in ~production environment

Peter Eisentraut pete...@gmx.net 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

Re: [HACKERS] Testing 9.2 in ~production environment

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

Re: [HACKERS] Testing 9.2 in ~production environment

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.

Re: [HACKERS] Testing 9.2 in ~production environment

JB == Josh Berkus j...@agliodbs.com 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';

[HACKERS] Testing 9.2 in ~production environment

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

Re: [HACKERS] Testing 9.2 in ~production environment

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, the

Re: [HACKERS] Testing 9.2 in ~production environment

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

Re: [HACKERS] Testing 9.2 in ~production environment

AF == Andres Freund and...@2ndquadrant.com 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

Re: [HACKERS] Testing 9.2 in ~production environment

PE == Peter Eisentraut pete...@gmx.net 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

Re: [HACKERS] testing ProcArrayLock patches

On Tue, Nov 22, 2011 at 4:40 AM, Kevin Grittner kevin.gritt...@wicourts.gov wrote: Pavan Deolasee pavan.deola...@gmail.com 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

Re: [HACKERS] testing ProcArrayLock patches

Pavan Deolasee pavan.deola...@gmail.com 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

Re: [HACKERS] testing ProcArrayLock patches

Kevin Grittner kevin.gritt...@wicourts.gov 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

Re: [HACKERS] testing ProcArrayLock patches

On Mon, Nov 21, 2011 at 10:44 PM, Kevin Grittner kevin.gritt...@wicourts.gov wrote: Kevin Grittner kevin.gritt...@wicourts.gov 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

Re: [HACKERS] testing ProcArrayLock patches

Pavan Deolasee pavan.deola...@gmail.com 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

Re: [HACKERS] testing ProcArrayLock patches

On Mon, Nov 21, 2011 at 11:01 PM, Kevin Grittner kevin.gritt...@wicourts.gov wrote: Pavan Deolasee pavan.deola...@gmail.com 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

Re: [HACKERS] testing ProcArrayLock patches

Pavan Deolasee pavan.deola...@gmail.com 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

Re: [HACKERS] testing ProcArrayLock patches

Robert Haas robertmh...@gmail.com 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

Re: [HACKERS] testing ProcArrayLock patches

Robert Haas robertmh...@gmail.com 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

Re: [HACKERS] testing ProcArrayLock patches

Robert Haas robertmh...@gmail.com 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

Re: [HACKERS] testing ProcArrayLock patches

On Fri, Nov 18, 2011 at 11:26 AM, Kevin Grittner kevin.gritt...@wicourts.gov wrote: Robert Haas robertmh...@gmail.com 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

Re: [HACKERS] testing ProcArrayLock patches

Robert Haas robertmh...@gmail.com 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

Re: [HACKERS] testing ProcArrayLock patches

Kevin Grittner kevin.gritt...@wicourts.gov 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

Re: [HACKERS] testing ProcArrayLock patches

On Fri, Nov 18, 2011 at 12:03 PM, Kevin Grittner kevin.gritt...@wicourts.gov 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

Re: [HACKERS] testing ProcArrayLock patches

Robert Haas robertmh...@gmail.com wrote: Kevin Grittner kevin.gritt...@wicourts.gov 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

Re: [HACKERS] testing ProcArrayLock patches

On Fri, Nov 18, 2011 at 12:45 PM, Kevin Grittner kevin.gritt...@wicourts.gov 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

Re: [HACKERS] testing ProcArrayLock patches

Robert Haas robertmh...@gmail.com 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

Re: [HACKERS] testing ProcArrayLock patches

Robert Haas robertmh...@gmail.com 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

Re: [HACKERS] testing ProcArrayLock patches

Kevin Grittner kevin.gritt...@wicourts.gov schrieb: Robert Haas robertmh...@gmail.com 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

Re: [HACKERS] testing ProcArrayLock patches

anara...@anarazel.de and...@anarazel.de wrote: Kevin Grittner kevin.gritt...@wicourts.gov schrieb: samples %image name symbol name 9333944.9651 postgresAllocSetAlloc 8484764.5134 postgresbase_yyparse 7195153.8274 postgresSearchCatCache

Re: [HACKERS] testing ProcArrayLock patches

Kevin Grittner kevin.gritt...@wicourts.gov 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

Re: [HACKERS] testing ProcArrayLock patches

Robert Haas robertmh...@gmail.com 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

Re: [HACKERS] testing ProcArrayLock patches

On Friday, November 18, 2011 08:36:59 PM Kevin Grittner wrote: Kevin Grittner kevin.gritt...@wicourts.gov 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

Re: [HACKERS] testing ProcArrayLock patches

Andres Freund and...@anarazel.de 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

Re: [HACKERS] testing ProcArrayLock patches

On Friday, November 18, 2011 09:16:01 PM Kevin Grittner wrote: Andres Freund and...@anarazel.de 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.

Re: [HACKERS] testing ProcArrayLock patches

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 and...@anarazel.de wrote: When doing line-level profiles I would suggest looking at the instructions. What's the best way to do that? I think

Re: [HACKERS] testing ProcArrayLock patches

Andres Freund and...@anarazel.de 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

Re: [HACKERS] testing ProcArrayLock patches

On Fri, Nov 18, 2011 at 2:05 PM, Kevin Grittner kevin.gritt...@wicourts.gov wrote: Robert Haas robertmh...@gmail.com 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

Re: [HACKERS] testing ProcArrayLock patches

Robert Haas robertmh...@gmail.com 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

Re: [HACKERS] testing ProcArrayLock patches

On Fri, Nov 18, 2011 at 6:46 PM, Kevin Grittner kevin.gritt...@wicourts.gov 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?

Re: [HACKERS] testing ProcArrayLock patches

On Saturday, November 19, 2011 12:18:07 AM Kevin Grittner wrote: Andres Freund and...@anarazel.de 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

[HACKERS] Testing for safe fetching of TOAST values

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

Re: [HACKERS] testing nested case-when scoping

On Wed, Jun 15, 2011 at 7:43 AM, Pavel Stehule pavel.steh...@gmail.com 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    

Re: [HACKERS] testing nested case-when scoping

2011/7/5 Robert Haas robertmh...@gmail.com: On Wed, Jun 15, 2011 at 7:43 AM, Pavel Stehule pavel.steh...@gmail.com 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;$$;

[HACKERS] testing nested case-when scoping

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$_$; CREATE

Re: [HACKERS] Testing extension upgrade scripts

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

[HACKERS] Testing extension upgrade scripts

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

Re: [HACKERS] Testing extension upgrade scripts

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. Load

Re: [HACKERS] Testing extension upgrade scripts

David E. Wheeler da...@kineticode.com 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

Re: [HACKERS] Testing extension upgrade scripts

David E. Wheeler da...@kineticode.com 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

Re: [HACKERS] testing plpython3u on 9.0beta3

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

Re: [HACKERS] testing plpython3u on 9.0beta3

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

[HACKERS] testing plpython3u on 9.0beta3

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.

Re: [HACKERS] testing plpython3u on 9.0beta3

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

Re: [HACKERS] testing plpython3u on 9.0beta3

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

Re: [HACKERS] testing plpython3u on 9.0beta3

Chris rfu...@gmail.com 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

Re: [HACKERS] testing plpython3u on 9.0beta2

On Fri, Jun 25, 2010 at 2:49 PM, Peter Eisentraut pete...@gmx.net wrote: On fre, 2010-06-25 at 10:17 -0400, Tom Lane wrote: Peter Eisentraut pete...@gmx.net writes: The problem is apparently that when CREATE LANGUAGE creates a language from a pg_pltemplate entry, it creates the proname from

Re: [HACKERS] testing plpython3u on 9.0beta2

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 last bump has

Re: [HACKERS] testing plpython3u on 9.0beta2

Bruce Momjian br...@momjian.us 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

Re: [HACKERS] testing plpython3u on 9.0beta2

Tom Lane wrote: Bruce Momjian br...@momjian.us 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

Re: [HACKERS] testing plpython3u on 9.0beta2

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 the

Re: [HACKERS] testing plpython3u on 9.0beta2

Peter Eisentraut pete...@gmx.net 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,

Re: [HACKERS] testing plpython3u on 9.0beta2

Peter Eisentraut pete...@gmx.net 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

Re: [HACKERS] testing plpython3u on 9.0beta2

On fre, 2010-06-25 at 10:17 -0400, Tom Lane wrote: Peter Eisentraut pete...@gmx.net 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,

Re: [HACKERS] testing plpython3u on 9.0beta2

Peter Eisentraut pete...@gmx.net 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

Re: [HACKERS] testing plpython3u on 9.0beta2

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 testing

Re: [HACKERS] testing plpython3u on 9.0beta2

On Wednesday 23 June 2010 16:30:54 Tom Lane wrote: Robert Haas robertmh...@gmail.com 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

Re: [HACKERS] testing plpython3u on 9.0beta2

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

Re: [HACKERS] testing plpython3u on 9.0beta2

On Wed, Jun 23, 2010 at 10:49 AM, Robert Haas robertmh...@gmail.com wrote: On Wed, Jun 23, 2010 at 10:30 AM, Tom Lane t...@sss.pgh.pa.us wrote: Robert Haas robertmh...@gmail.com writes: I can reproduce this, here.  The problem seems to be that plpython only build either plpython2.so or

Re: [HACKERS] testing plpython3u on 9.0beta2

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,

Re: [HACKERS] testing plpython3u on 9.0beta2

On Tue, Jun 22, 2010 at 10:41 PM, Chris rfu...@gmail.com wrote: I received two errors (described below) in installing 9.0beta2 on Kubuntu 10.04 , RhodiumToad on IRC recommended I post them here. I did not have a 2.x or 3.x python dev installed, but I was really only interested in python3 via

  1   2   3   4   5   >