[HACKERS] Oid?
hi everyone i see an attribute 'oid_value' with 'Oid' type in the ListCell union. can anyone tell me what does it represents? Thank you __ Do you Yahoo!? Yahoo! Mail - Easier than ever with enhanced search. Learn more. http://info.mail.yahoo.com/mail_250 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Oid?
On Mon, 2004-12-06 at 00:29 -0800, Sibtay Abbas wrote: i see an attribute 'oid_value' with 'Oid' type in the ListCell union. can anyone tell me what does it represents? Given a linked list of type T_OidList, oid_value holds the data in a node of the list. Although int_value and oid_value are the same size at the moment, (a) Oid is unsigned (b) there has been some thought about changing the size of Oid (to make it 64-bit). While (b) isn't likely to happen anytime soon AFAIK, the two types of lists are kept separate. This also helps to reduce the need for casting. -Neil ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[HACKERS] main entry point for queries?
hello i am trying to understand the source code of postgresql. Whenever a user enters a query, whether from the Socket end or the interactive back end, which function is always invoked that would start manipulation of that query... i ve noticed that the primitive parsing is done by the raw_parser() function which is called by pg_parse_query() is pg_parse_query() the main entry point for all queries? thank you __ Do you Yahoo!? Yahoo! Mail - You care about security. So do we. http://promotions.yahoo.com/new_mail ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] postgresql-7.4.5
On Mon, 6 Dec 2004, ElayaRaja S wrote: I am using postgresql-7.4.5. I nee to use the jdbc connection So i downloaded 4 versions of driver( pg74.215.jdbc1.jar, pg74.215.jdbc2.jar, pg74.215.jdbc2ee.jar, pg74.215.jdbc3.jar). I am uanble to connect it. Please let me know which version of driver i have to use for postgresql-7.4.5 ? This question is inappropriate for the -hackers list. Please keep it on -interfaces or the more appropriate -jdbc list. As mentioned on the page you downloaded these drivers from, you should use the driver version that matches your JVM. Without any information on what your actual problem is, no one will be able to help you. Kris Jurka ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] DBD::PgSPI 0.02
On Mon, 6 Dec 2004 00:27:18 -0500 (EST), [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hello, A short note that I've updated DBD::PgSPI version 0.02 to CPAN. There are no new features - but the code now expects (and works with) reasonably decent versions of perl (5.8.x) and pgsql (8.x). Just so that you have some info, I've been using DBD::PgSPI with Pg 8.0 since beta 1. The only restriction I've run into with the old code is that it doesn't like the DBD 'do' method. I have to use execute/fetchX or selectX, but other than that it seems to work. I'll be grabbing the update to test soon. No warranty is given, this code compiles and 'scratches my itch'. If it happens to scratch yours, more the merrier. Thanks for scratching your itch! I'm sure you're merrie than you know. :) -alex ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly -- Mike Rylander [EMAIL PROTECTED] GPLS -- PINES Development Database Developer http://open-ils.org ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] DBD::PgSPI 0.02
On Mon, 6 Dec 2004, Mike Rylander wrote: Just so that you have some info, I've been using DBD::PgSPI with Pg 8.0 since beta 1. The only restriction I've run into with the old code is that it doesn't like the DBD 'do' method. I have to use execute/fetchX or selectX, but other than that it seems to work. I'll be grabbing the update to test soon. 'do' seems to work for me. What happens for you? I put a version of code with a bit more fixes from comments onlist to www.pilosoft.com/PgSPI/DBD-PgSPI-0.03pre.tar.gz Please download and try it. -alex ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] DBD::PgSPI 0.02
On Mon, 6 Dec 2004 08:17:29 -0500 (EST), [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: On Mon, 6 Dec 2004, Mike Rylander wrote: Just so that you have some info, I've been using DBD::PgSPI with Pg 8.0 since beta 1. The only restriction I've run into with the old code is that it doesn't like the DBD 'do' method. I have to use execute/fetchX or selectX, but other than that it seems to work. I'll be grabbing the update to test soon. 'do' seems to work for me. What happens for you? With v. 0.01 the statement just doesn't seem to execute. I know that's odd, because it's supposed to be doing a prepare/execute internally, but nothing happens. I put a version of code with a bit more fixes from comments onlist to www.pilosoft.com/PgSPI/DBD-PgSPI-0.03pre.tar.gz Please download and try it. I'll grab it now, but I'm not sure when I'll have time to test it. I'm mired in Unicode work right now... I'll get back to you as soon as I've had a chance to work with it, though. -alex Again, thanks for all your work on PgSPI. I'll be moving all my plperlu functions out to a module and using PgSPI to allow me to run the code from my middleware layer as well as in-DB. That way I only need to write the logic once. -- Mike Rylander [EMAIL PROTECTED] GPLS -- PINES Development Database Developer http://open-ils.org ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] DBD::PgSPI 0.02
On Mon, 6 Dec 2004, Mike Rylander wrote: With v. 0.01 the statement just doesn't seem to execute. I know that's odd, because it's supposed to be doing a prepare/execute internally, but nothing happens. Wierd - the testsuite (make test) has some 'dos' in the code and it works (and it checks the result of inserts that are done with do). I'll grab it now, but I'm not sure when I'll have time to test it. I'm mired in Unicode work right now... I'll get back to you as soon as I've had a chance to work with it, though. Yeah - I'm not doing any utf translation in pgspi - this might become necessary for you... Again, thanks for all your work on PgSPI. I'll be moving all my plperlu functions out to a module and using PgSPI to allow me to run the code from my middleware layer as well as in-DB. That way I only need to write the logic once. Yep, that's kind of was the point, making postgresql itself a middleware server. Make perl stored procedures take serialized objects and return serialized objects back. -alex ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Need access to a Linux box
OSDL provides hardware. You have to sign up for a login here: https://www.osdl.org/join_form And submit a project proposal here: https://www.osdl.org/lab_activities/lab_projects/a_propose_project/propose_a_project.html Mark ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] V8 Beta 5 on AIX
I tried compliling v8 beta 5 (grabbed from cvs on Friday) on AIX 5.1. It fails during the make make[4]: Entering directory `/opt/OXRS/Sources/pgsql-HEAD/src/interfaces/libpq' make[4]: Nothing to be done for `all'. make[4]: Leaving directory `/opt/OXRS/Sources/pgsql-HEAD/src/interfaces/libpq' make[4]: Entering directory `/opt/OXRS/Sources/pgsql-HEAD/src/port' make[4]: Nothing to be done for `all'. make[4]: Leaving directory `/opt/OXRS/Sources/pgsql-HEAD/src/port' gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wendif-labels -fno-strict-aliasing -g pg_ctl.o -L../../../src/interfaces/libpq -lpq -L../../../src/port -L/opt/OXRS/supporting-packages/readline-4.2/lib -L/opt/OXRS/supporting-packages/zlib-1.1.4 -lpgport -lz -lreadline -lcurses -lPW -lld -lnsl -ldl -lm -o pg_ctl ld: 0711-317 ERROR: Undefined symbol: .pthread_sigmask ld: 0711-317 ERROR: Undefined symbol: .sigwait ld: 0711-317 ERROR: Undefined symbol: .pthread_mutex_lock ld: 0711-317 ERROR: Undefined symbol: .pthread_mutex_unlock ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information. collect2: ld returned 8 exit status make[3]: *** [pg_ctl] Error 1 make[3]: Leaving directory `/opt/OXRS/Sources/pgsql-HEAD/src/bin/pg_ctl' make[2]: *** [all] Error 2 make[2]: Leaving directory `/opt/OXRS/Sources/pgsql-HEAD/src/bin' make[1]: *** [all] Error 2 make[1]: Leaving directory `/opt/OXRS/Sources/pgsql-HEAD/src' make: *** [all] Error 2 Brad. ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] V8 Beta 5 on AIX
Brad Nicholson wrote: I tried compliling v8 beta 5 (grabbed from cvs on Friday) on AIX 5.1. It fails during the make make[4]: Entering directory `/opt/OXRS/Sources/pgsql-HEAD/src/interfaces/libpq' make[4]: Nothing to be done for `all'. make[4]: Leaving directory `/opt/OXRS/Sources/pgsql-HEAD/src/interfaces/libpq' make[4]: Entering directory `/opt/OXRS/Sources/pgsql-HEAD/src/port' make[4]: Nothing to be done for `all'. make[4]: Leaving directory `/opt/OXRS/Sources/pgsql-HEAD/src/port' gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wendif-labels -fno-strict-aliasing -g pg_ctl.o -L../../../src/interfaces/libpq -lpq -L../../../src/port -L/opt/OXRS/supporting-packages/readline-4.2/lib -L/opt/OXRS/supporting-packages/zlib-1.1.4 -lpgport -lz -lreadline -lcurses -lPW -lld -lnsl -ldl -lm -o pg_ctl ld: 0711-317 ERROR: Undefined symbol: .pthread_sigmask ld: 0711-317 ERROR: Undefined symbol: .sigwait ld: 0711-317 ERROR: Undefined symbol: .pthread_mutex_lock ld: 0711-317 ERROR: Undefined symbol: .pthread_mutex_unlock ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information. collect2: ld returned 8 exit status make[3]: *** [pg_ctl] Error 1 make[3]: Leaving directory `/opt/OXRS/Sources/pgsql-HEAD/src/bin/pg_ctl' make[2]: *** [all] Error 2 make[2]: Leaving directory `/opt/OXRS/Sources/pgsql-HEAD/src/bin' make[1]: *** [all] Error 2 make[1]: Leaving directory `/opt/OXRS/Sources/pgsql-HEAD/src' make: *** [all] Error 2 OK, I assume you used --enable-thread-safety in configure. This should have added some PTHREAD link flags to your libpq build, and those settings should have followed the libpq library into your pg_ctl link line. Would you look in your Makefile.global for PTHREAD_* settings and report those. The second question is why saying those libraries are needed by libpq is not passing down to uses of libpq, like in pg_ctl. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
[HACKERS] arm rc1 regression failures
Just compiled RC1 on a netwinder ARM system running Debian Linux (sarge). All
tests passed except point with the
following in results/point
Jim
--
-- POINT
--
CREATE TABLE POINT_TBL(f1 point);
INSERT INTO POINT_TBL(f1) VALUES ('(0.0,0.0)');
INSERT INTO POINT_TBL(f1) VALUES ('(-10.0,0.0)');
INSERT INTO POINT_TBL(f1) VALUES ('(-3.0,4.0)');
INSERT INTO POINT_TBL(f1) VALUES ('(5.1, 34.5)');
INSERT INTO POINT_TBL(f1) VALUES ('(-5.0,-12.0)');
-- bad format points
INSERT INTO POINT_TBL(f1) VALUES ('asdfasdf');
ERROR: invalid input syntax for type point: asdfasdf
INSERT INTO POINT_TBL(f1) VALUES ('10.0,10.0');
INSERT INTO POINT_TBL(f1) VALUES ('(10.0 10.0)');
ERROR: invalid input syntax for type point: (10.0 10.0)
INSERT INTO POINT_TBL(f1) VALUES ('(10.0,10.0');
ERROR: invalid input syntax for type point: (10.0,10.0
SELECT '' AS six, POINT_TBL.*;
six | f1
-+
| (0,0)
| (-10,0)
| (-3,4)
| (5.1,34.5)
| (-5,-12)
| (10,10)
(6 rows)
-- left of
SELECT '' AS three, p.* FROM POINT_TBL p WHERE p.f1 '(0.0, 0.0)';
three |f1
---+--
| (-10,0)
| (-3,4)
| (-5,-12)
(3 rows)
-- right of
SELECT '' AS three, p.* FROM POINT_TBL p WHERE '(0.0,0.0)' p.f1;
three |f1
---+--
| (-10,0)
| (-3,4)
| (-5,-12)
(3 rows)
-- above
SELECT '' AS one, p.* FROM POINT_TBL p WHERE '(0.0,0.0)' ^ p.f1;
one |f1
-+--
| (-5,-12)
(1 row)
-- below
SELECT '' AS one, p.* FROM POINT_TBL p WHERE p.f1 ^ '(0.0, 0.0)';
one |f1
-+--
| (-5,-12)
(1 row)
-- equal
SELECT '' AS one, p.* FROM POINT_TBL p WHERE p.f1 ~= '(5.1, 34.5)';
one | f1
-+
| (5.1,34.5)
(1 row)
-- point in box
SELECT '' AS three, p.* FROM POINT_TBL p
WHERE p.f1 @ box '(0,0,100,100)';
three | f1
---+
| (0,0)
| (5.1,34.5)
| (10,10)
(3 rows)
SELECT '' AS three, p.* FROM POINT_TBL p
WHERE not p.f1 @ box '(0,0,100,100)';
three |f1
---+--
| (-10,0)
| (-3,4)
| (-5,-12)
(3 rows)
SELECT '' AS two, p.* FROM POINT_TBL p
WHERE p.f1 @ path '[(0,0),(-10,0),(-10,10)]';
two | f1
-+-
| (0,0)
| (-10,0)
(2 rows)
SELECT '' AS six, p.f1, p.f1 - point '(0,0)' AS dist
FROM POINT_TBL p
ORDER BY dist;
six | f1 | dist
-++--
| (0,0) |0
| (-3,4) |5
| (-10,0)| 10
| (-5,-12) | 13
| (10,10)| 14.1421356237309
| (5.1,34.5) | 34.8749193547455
(6 rows)
SET geqo TO 'off';
SELECT '' AS thirtysix, p1.f1 AS point1, p2.f1 AS point2, p1.f1 - p2.f1 AS
dist
FROM POINT_TBL p1, POINT_TBL p2
ORDER BY dist, point1 using , point2 using ;
thirtysix | point1 | point2 | dist
---+++--
| (-10,0)| (-10,0)|0
| (-5,-12) | (-5,-12) |0
| (-3,4) | (-3,4) |0
| (0,0) | (0,0) |0
| (5.1,34.5) | (5.1,34.5) |0
| (10,10)| (10,10)|0
| (-3,4) | (0,0) |5
| (0,0) | (-3,4) |5
| (-10,0)| (-3,4) | 8.06225774829855
| (-3,4) | (-10,0)| 8.06225774829855
| (-10,0)| (0,0) | 10
| (0,0) | (-10,0)| 10
| (-10,0)| (-5,-12) | 13
| (-5,-12) | (-10,0)| 13
| (-5,-12) | (0,0) | 13
| (0,0) | (-5,-12) | 13
| (0,0) | (10,10)| 14.1421356237309
| (10,10)| (0,0) | 14.1421356237309
| (-3,4) | (10,10)| 14.3178210632764
| (10,10)| (-3,4) | 14.3178210632764
| (-5,-12) | (-3,4) | 16.1245154965971
| (-3,4) | (-5,-12) | 16.1245154965971
| (-10,0)| (10,10)| 22.3606797749979
| (10,10)| (-10,0)| 22.3606797749979
| (5.1,34.5) | (10,10)| 24.9851956166046
| (10,10)| (5.1,34.5) | 24.9851956166046
| (-5,-12) | (10,10)| 26.6270539113887
| (10,10)| (-5,-12) | 26.6270539113887
| (-3,4) | (5.1,34.5) | 31.5572495632937
| (5.1,34.5) | (-3,4) | 31.5572495632937
| (0,0) | (5.1,34.5) | 34.8749193547455
| (5.1,34.5) | (0,0) | 34.8749193547455
| (-10,0)| (5.1,34.5) | 37.6597928831267
| (5.1,34.5) | (-10,0)| 37.6597928831267
| (-5,-12) | (5.1,34.5) | 47.5842410888311
| (5.1,34.5) | (-5,-12)
Re: [HACKERS] arm rc1 regression failures
Would you send us regression.diff? That should show the differences.
---
Jim Buttafuoco wrote:
Just compiled RC1 on a netwinder ARM system running Debian Linux (sarge).
All tests passed except point with the
following in results/point
Jim
--
-- POINT
--
CREATE TABLE POINT_TBL(f1 point);
INSERT INTO POINT_TBL(f1) VALUES ('(0.0,0.0)');
INSERT INTO POINT_TBL(f1) VALUES ('(-10.0,0.0)');
INSERT INTO POINT_TBL(f1) VALUES ('(-3.0,4.0)');
INSERT INTO POINT_TBL(f1) VALUES ('(5.1, 34.5)');
INSERT INTO POINT_TBL(f1) VALUES ('(-5.0,-12.0)');
-- bad format points
INSERT INTO POINT_TBL(f1) VALUES ('asdfasdf');
ERROR: invalid input syntax for type point: asdfasdf
INSERT INTO POINT_TBL(f1) VALUES ('10.0,10.0');
INSERT INTO POINT_TBL(f1) VALUES ('(10.0 10.0)');
ERROR: invalid input syntax for type point: (10.0 10.0)
INSERT INTO POINT_TBL(f1) VALUES ('(10.0,10.0');
ERROR: invalid input syntax for type point: (10.0,10.0
SELECT '' AS six, POINT_TBL.*;
six | f1
-+
| (0,0)
| (-10,0)
| (-3,4)
| (5.1,34.5)
| (-5,-12)
| (10,10)
(6 rows)
-- left of
SELECT '' AS three, p.* FROM POINT_TBL p WHERE p.f1 '(0.0, 0.0)';
three |f1
---+--
| (-10,0)
| (-3,4)
| (-5,-12)
(3 rows)
-- right of
SELECT '' AS three, p.* FROM POINT_TBL p WHERE '(0.0,0.0)' p.f1;
three |f1
---+--
| (-10,0)
| (-3,4)
| (-5,-12)
(3 rows)
-- above
SELECT '' AS one, p.* FROM POINT_TBL p WHERE '(0.0,0.0)' ^ p.f1;
one |f1
-+--
| (-5,-12)
(1 row)
-- below
SELECT '' AS one, p.* FROM POINT_TBL p WHERE p.f1 ^ '(0.0, 0.0)';
one |f1
-+--
| (-5,-12)
(1 row)
-- equal
SELECT '' AS one, p.* FROM POINT_TBL p WHERE p.f1 ~= '(5.1, 34.5)';
one | f1
-+
| (5.1,34.5)
(1 row)
-- point in box
SELECT '' AS three, p.* FROM POINT_TBL p
WHERE p.f1 @ box '(0,0,100,100)';
three | f1
---+
| (0,0)
| (5.1,34.5)
| (10,10)
(3 rows)
SELECT '' AS three, p.* FROM POINT_TBL p
WHERE not p.f1 @ box '(0,0,100,100)';
three |f1
---+--
| (-10,0)
| (-3,4)
| (-5,-12)
(3 rows)
SELECT '' AS two, p.* FROM POINT_TBL p
WHERE p.f1 @ path '[(0,0),(-10,0),(-10,10)]';
two | f1
-+-
| (0,0)
| (-10,0)
(2 rows)
SELECT '' AS six, p.f1, p.f1 - point '(0,0)' AS dist
FROM POINT_TBL p
ORDER BY dist;
six | f1 | dist
-++--
| (0,0) |0
| (-3,4) |5
| (-10,0)| 10
| (-5,-12) | 13
| (10,10)| 14.1421356237309
| (5.1,34.5) | 34.8749193547455
(6 rows)
SET geqo TO 'off';
SELECT '' AS thirtysix, p1.f1 AS point1, p2.f1 AS point2, p1.f1 - p2.f1 AS
dist
FROM POINT_TBL p1, POINT_TBL p2
ORDER BY dist, point1 using , point2 using ;
thirtysix | point1 | point2 | dist
---+++--
| (-10,0)| (-10,0)|0
| (-5,-12) | (-5,-12) |0
| (-3,4) | (-3,4) |0
| (0,0) | (0,0) |0
| (5.1,34.5) | (5.1,34.5) |0
| (10,10)| (10,10)|0
| (-3,4) | (0,0) |5
| (0,0) | (-3,4) |5
| (-10,0)| (-3,4) | 8.06225774829855
| (-3,4) | (-10,0)| 8.06225774829855
| (-10,0)| (0,0) | 10
| (0,0) | (-10,0)| 10
| (-10,0)| (-5,-12) | 13
| (-5,-12) | (-10,0)| 13
| (-5,-12) | (0,0) | 13
| (0,0) | (-5,-12) | 13
| (0,0) | (10,10)| 14.1421356237309
| (10,10)| (0,0) | 14.1421356237309
| (-3,4) | (10,10)| 14.3178210632764
| (10,10)| (-3,4) | 14.3178210632764
| (-5,-12) | (-3,4) | 16.1245154965971
| (-3,4) | (-5,-12) | 16.1245154965971
| (-10,0)| (10,10)| 22.3606797749979
| (10,10)| (-10,0)| 22.3606797749979
| (5.1,34.5) | (10,10)| 24.9851956166046
| (10,10)| (5.1,34.5) | 24.9851956166046
| (-5,-12) | (10,10)| 26.6270539113887
| (10,10)| (-5,-12) | 26.6270539113887
| (-3,4) | (5.1,34.5) | 31.5572495632937
| (5.1,34.5) | (-3,4) |
Re: [HACKERS] V8 Beta 5 on AIX
Bruce Momjian wrote: Brad Nicholson wrote: I tried compliling v8 beta 5 (grabbed from cvs on Friday) on AIX 5.1. It fails during the make make[4]: Entering directory `/opt/OXRS/Sources/pgsql-HEAD/src/interfaces/libpq' make[4]: Nothing to be done for `all'. make[4]: Leaving directory `/opt/OXRS/Sources/pgsql-HEAD/src/interfaces/libpq' make[4]: Entering directory `/opt/OXRS/Sources/pgsql-HEAD/src/port' make[4]: Nothing to be done for `all'. make[4]: Leaving directory `/opt/OXRS/Sources/pgsql-HEAD/src/port' gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wendif-labels -fno-strict-aliasing -g pg_ctl.o -L../../../src/interfaces/libpq -lpq -L../../../src/port -L/opt/OXRS/supporting-packages/readline-4.2/lib -L/opt/OXRS/supporting-packages/zlib-1.1.4 -lpgport -lz -lreadline -lcurses -lPW -lld -lnsl -ldl -lm -o pg_ctl ld: 0711-317 ERROR: Undefined symbol: .pthread_sigmask ld: 0711-317 ERROR: Undefined symbol: .sigwait ld: 0711-317 ERROR: Undefined symbol: .pthread_mutex_lock ld: 0711-317 ERROR: Undefined symbol: .pthread_mutex_unlock ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information. collect2: ld returned 8 exit status make[3]: *** [pg_ctl] Error 1 make[3]: Leaving directory `/opt/OXRS/Sources/pgsql-HEAD/src/bin/pg_ctl' make[2]: *** [all] Error 2 make[2]: Leaving directory `/opt/OXRS/Sources/pgsql-HEAD/src/bin' make[1]: *** [all] Error 2 make[1]: Leaving directory `/opt/OXRS/Sources/pgsql-HEAD/src' make: *** [all] Error 2 OK, I assume you used --enable-thread-safety in configure. Correct. This should have added some PTHREAD link flags to your libpq build, and those settings should have followed the libpq library into your pg_ctl link line. Would you look in your Makefile.global for PTHREAD_* settings and report those. The second question is why saying those libraries are needed by libpq is not passing down to uses of libpq, like in pg_ctl. PTHREAD_CFLAGS =-pthread -D_REENTRANT -D_THREAD_SAFE -D_POSIX_PTHREAD_SEMANTICS PTHREAD_LIBS= -lpthread -lpthreads Brad. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] arm rc1 regression failures
See attached
-- Original Message ---
From: Bruce Momjian [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: pgsql-hackers [EMAIL PROTECTED]
Sent: Mon, 6 Dec 2004 12:24:18 -0500 (EST)
Subject: Re: [HACKERS] arm rc1 regression failures
Would you send us regression.diff? That should show the differences.
---
Jim Buttafuoco wrote:
Just compiled RC1 on a netwinder ARM system running Debian Linux (sarge).
All tests passed except point with
the
following in results/point
Jim
--
-- POINT
--
CREATE TABLE POINT_TBL(f1 point);
INSERT INTO POINT_TBL(f1) VALUES ('(0.0,0.0)');
INSERT INTO POINT_TBL(f1) VALUES ('(-10.0,0.0)');
INSERT INTO POINT_TBL(f1) VALUES ('(-3.0,4.0)');
INSERT INTO POINT_TBL(f1) VALUES ('(5.1, 34.5)');
INSERT INTO POINT_TBL(f1) VALUES ('(-5.0,-12.0)');
-- bad format points
INSERT INTO POINT_TBL(f1) VALUES ('asdfasdf');
ERROR: invalid input syntax for type point: asdfasdf
INSERT INTO POINT_TBL(f1) VALUES ('10.0,10.0');
INSERT INTO POINT_TBL(f1) VALUES ('(10.0 10.0)');
ERROR: invalid input syntax for type point: (10.0 10.0)
INSERT INTO POINT_TBL(f1) VALUES ('(10.0,10.0');
ERROR: invalid input syntax for type point: (10.0,10.0
SELECT '' AS six, POINT_TBL.*;
six | f1
-+
| (0,0)
| (-10,0)
| (-3,4)
| (5.1,34.5)
| (-5,-12)
| (10,10)
(6 rows)
-- left of
SELECT '' AS three, p.* FROM POINT_TBL p WHERE p.f1 '(0.0, 0.0)';
three |f1
---+--
| (-10,0)
| (-3,4)
| (-5,-12)
(3 rows)
-- right of
SELECT '' AS three, p.* FROM POINT_TBL p WHERE '(0.0,0.0)' p.f1;
three |f1
---+--
| (-10,0)
| (-3,4)
| (-5,-12)
(3 rows)
-- above
SELECT '' AS one, p.* FROM POINT_TBL p WHERE '(0.0,0.0)' ^ p.f1;
one |f1
-+--
| (-5,-12)
(1 row)
-- below
SELECT '' AS one, p.* FROM POINT_TBL p WHERE p.f1 ^ '(0.0, 0.0)';
one |f1
-+--
| (-5,-12)
(1 row)
-- equal
SELECT '' AS one, p.* FROM POINT_TBL p WHERE p.f1 ~= '(5.1, 34.5)';
one | f1
-+
| (5.1,34.5)
(1 row)
-- point in box
SELECT '' AS three, p.* FROM POINT_TBL p
WHERE p.f1 @ box '(0,0,100,100)';
three | f1
---+
| (0,0)
| (5.1,34.5)
| (10,10)
(3 rows)
SELECT '' AS three, p.* FROM POINT_TBL p
WHERE not p.f1 @ box '(0,0,100,100)';
three |f1
---+--
| (-10,0)
| (-3,4)
| (-5,-12)
(3 rows)
SELECT '' AS two, p.* FROM POINT_TBL p
WHERE p.f1 @ path '[(0,0),(-10,0),(-10,10)]';
two | f1
-+-
| (0,0)
| (-10,0)
(2 rows)
SELECT '' AS six, p.f1, p.f1 - point '(0,0)' AS dist
FROM POINT_TBL p
ORDER BY dist;
six | f1 | dist
-++--
| (0,0) |0
| (-3,4) |5
| (-10,0)| 10
| (-5,-12) | 13
| (10,10)| 14.1421356237309
| (5.1,34.5) | 34.8749193547455
(6 rows)
SET geqo TO 'off';
SELECT '' AS thirtysix, p1.f1 AS point1, p2.f1 AS point2, p1.f1 - p2.f1
AS dist
FROM POINT_TBL p1, POINT_TBL p2
ORDER BY dist, point1 using , point2 using ;
thirtysix | point1 | point2 | dist
---+++--
| (-10,0)| (-10,0)|0
| (-5,-12) | (-5,-12) |0
| (-3,4) | (-3,4) |0
| (0,0) | (0,0) |0
| (5.1,34.5) | (5.1,34.5) |0
| (10,10)| (10,10)|0
| (-3,4) | (0,0) |5
| (0,0) | (-3,4) |5
| (-10,0)| (-3,4) | 8.06225774829855
| (-3,4) | (-10,0)| 8.06225774829855
| (-10,0)| (0,0) | 10
| (0,0) | (-10,0)| 10
| (-10,0)| (-5,-12) | 13
| (-5,-12) | (-10,0)| 13
| (-5,-12) | (0,0) | 13
| (0,0) | (-5,-12) | 13
| (0,0) | (10,10)| 14.1421356237309
| (10,10)| (0,0) | 14.1421356237309
| (-3,4) | (10,10)| 14.3178210632764
| (10,10)| (-3,4) | 14.3178210632764
| (-5,-12) | (-3,4) | 16.1245154965971
| (-3,4) | (-5,-12) | 16.1245154965971
| (-10,0)| (10,10)|
Re: [Testperf-general] Re: [HACKERS] 8.0beta5 results w/ dbt2
On Tue, Nov 30, 2004 at 10:51:42PM +, Simon Riggs wrote: My suggestion: increase checkpoint_timeout to 600 secs, increase bgwriter parameters also, to reduce how frequently it is called, as well as increase the number of blocks per cycle. Ok, here are a series of three tests varying the bgwriter_delay at 1, 50, and 100: http://www.osdl.org/projects/dbt2dev/results/pgsql/bgwriter_delay/ I also reduced checkpoint_timeout to 600, where it was prevously at 1800 with the results I posted previously. The throughput changes weren't significant and the oprofile data is more of less the same. I'll try varying the bgwriter_maxpages next (that's the number of blocks per cycle, right?) Mark ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [Testperf-general] Re: [HACKERS] 8.0beta5 results w/ dbt2
Mark, Ok, here are a series of three tests varying the bgwriter_delay at 1, 50, and 100: http://www.osdl.org/projects/dbt2dev/results/pgsql/bgwriter_delay/ Hmmm. Looks inconclusive. The differences between the runs are 0.3%, which is a margin of error by anyone's definition. Will have to develop better tests ... -- Josh Berkus Aglio Database Solutions San Francisco ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] V8 Beta 5 on AIX
Brad Nicholson wrote:
OK, I assume you used --enable-thread-safety in configure.
Correct.
This should
have added some PTHREAD link flags to your libpq build, and those
settings should have followed the libpq library into your pg_ctl link
line.
Would you look in your Makefile.global for PTHREAD_* settings and report
those. The second question is why saying those libraries are needed by
libpq is not passing down to uses of libpq, like in pg_ctl.
PTHREAD_CFLAGS =-pthread -D_REENTRANT -D_THREAD_SAFE
-D_POSIX_PTHREAD_SEMANTICS
PTHREAD_LIBS= -lpthread -lpthreads
OK, great. Can I see the link line that creates libpq? It should contain
the PTHREAD_LIBS flags.
If it does, the next question is why AIX doesn't pass those flags.
Oh, I think I see the cause. I now remember from
config/acx_pthread.m4:
# More AIX lossage: must compile with cc_r
AC_CHECK_PROG(PTHREAD_CC, cc_r, cc_r, ${CC})
Seems AIX wants a special _compiler_ to be used whenever threading is
involved, even by a linked-in library. I didn't implement using
PTHREAD_CC because there was just too much code disruption for threading
on one platform. I wonder if we should just disable threading on AIX.
Let me ask --- if you change the CC line in Makefile.global to cc_r,
does everything build OK? That might be a clean solution because the
change could be made in one place. Of course this would mean the
backend would also be compiled using cc_r and I have no idea of the
effect.
Of course, the idea that any use of libpq has to use cc_r is going to
make building things complex without some adjustments.
Also, what version of AIX are you using? Are other AIX folks having
thread build problems?
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup.| Newtown Square, Pennsylvania 19073
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] V8 Beta 5 on AIX
Brad Nicholson wrote: I tried compliling v8 beta 5 (grabbed from cvs on Friday) on AIX 5.1. I see now you are running AIX 5.1. Is that a fairly modern/popular version of AIX? -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] DBD::PgSPI 0.02
On Mon, Dec 06, 2004 at 08:17:29AM -0500, [EMAIL PROTECTED] wrote: I put a version of code with a bit more fixes from comments onlist to www.pilosoft.com/PgSPI/DBD-PgSPI-0.03pre.tar.gz After correcting the path (no directory) I downloaded this and it built without changes on FreeBSD 4.10-STABLE and Solaris 9, both running PostgreSQL 8.0.0rc1 and Perl 5.8.6. However, something changed since 0.02 that broke queries on FreeBSD (but not on Solaris). Here's an example: CREATE FUNCTION test() RETURNS INTEGER AS $$ use DBD::PgSPI; elog INFO, DBD::PgSPI $DBD::PgSPI::VERSION; my @row = $pg_dbh-selectrow_array(SELECT 12345); return $row[0]; $$ LANGUAGE plperlu; If I install DBD::PgSPI 0.02 I get this: SELECT test(); INFO: DBD::PgSPI 0.02 test --- 12345 (1 row) If I disconnect, install DBD::PgSPI 0.03pre, then reconnect and run the same query, I get this: SELECT test(); INFO: DBD::PgSPI 0.03pre test -- (1 row) Any idea what might have changed between 0.02 and 0.03pre that would affect some platforms but not others? A few other comments: The README file says that plperl is NOT part of latest (7.1) distribution The latest release is now 7.4.6 with 8.0.0 coming soon, and both include plperl. The TODO section in the README file has items for Support for returning rows and sets of rows and Support for writing trigger handlers. In 8.0 PL/Perl has these capabilities. -- Michael Fuhr http://www.fuhr.org/~mfuhr/ ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] arm rc1 regression failures
Jim Buttafuoco wrote: See attached Well, that test passed for the last release, so what changed in between? I don't think we changed the floating-point output again, did we? -- Peter Eisentraut http://learn.to/quote ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] DBD::PgSPI 0.02
BTW, I would like to get these capabilities into core plperl. There are some obstacles to overcome. For example: . not every perl installation has DBI . how to turn it on for trusted plperl . DBD::PgSPI is covered by GPL, which means it can't be used in the core distribution of postgres - we'd have to reinvent it in a clean room fashion. cheers andrew Michael Fuhr wrote: On Mon, Dec 06, 2004 at 08:17:29AM -0500, [EMAIL PROTECTED] wrote: I put a version of code with a bit more fixes from comments onlist to www.pilosoft.com/PgSPI/DBD-PgSPI-0.03pre.tar.gz After correcting the path (no directory) I downloaded this and it built without changes on FreeBSD 4.10-STABLE and Solaris 9, both running PostgreSQL 8.0.0rc1 and Perl 5.8.6. However, something changed since 0.02 that broke queries on FreeBSD (but not on Solaris). Here's an example: CREATE FUNCTION test() RETURNS INTEGER AS $$ use DBD::PgSPI; elog INFO, DBD::PgSPI $DBD::PgSPI::VERSION; my @row = $pg_dbh-selectrow_array(SELECT 12345); return $row[0]; $$ LANGUAGE plperlu; If I install DBD::PgSPI 0.02 I get this: SELECT test(); INFO: DBD::PgSPI 0.02 test --- 12345 (1 row) If I disconnect, install DBD::PgSPI 0.03pre, then reconnect and run the same query, I get this: SELECT test(); INFO: DBD::PgSPI 0.03pre test -- (1 row) Any idea what might have changed between 0.02 and 0.03pre that would affect some platforms but not others? A few other comments: The README file says that plperl is NOT part of latest (7.1) distribution The latest release is now 7.4.6 with 8.0.0 coming soon, and both include plperl. The TODO section in the README file has items for Support for returning rows and sets of rows and Support for writing trigger handlers. In 8.0 PL/Perl has these capabilities. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] DBD::PgSPI 0.02
On Mon, 6 Dec 2004, Andrew Dunstan wrote: BTW, I would like to get these capabilities into core plperl. There is already spi_exec_query in pl/perl for quick and dirty DB access for this purpose, no? There are some obstacles to overcome. For example: . not every perl installation has DBI Sure - I suppose if you don't have DBI, you would use spi_exec_query, no? . how to turn it on for trusted plperl Eh, you don't turn it on. You install the package and it works ;) . DBD::PgSPI is covered by GPL, which means it can't be used in the core distribution of postgres - we'd have to reinvent it in a clean room fashion. Actually, its both GPL and Artistic license - identical to DBD::Pg (where most of the code is taken from). I don't think this needs to be in core distribution - much like DBD::Pg doesn't need to be there either... -alex ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] DBD::PgSPI 0.02
On Mon, Dec 06, 2004 at 11:44:20AM -0700, Michael Fuhr wrote: After correcting the path (no directory) I downloaded this and it built without changes on FreeBSD 4.10-STABLE and Solaris 9, both running PostgreSQL 8.0.0rc1 and Perl 5.8.6. However, something changed since 0.02 that broke queries on FreeBSD (but not on Solaris). Never mind -- operator error. The FreeBSD box has multiple versions of PostgreSQL installed and I was getting the wrong pg_config when building DBD::PgSPI for 8.0 (that's what I get for mentioning pg_config). Sorry for the bogus report. -- Michael Fuhr http://www.fuhr.org/~mfuhr/ ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] DBD::PgSPI 0.02
[EMAIL PROTECTED] writes: On Mon, 6 Dec 2004, Andrew Dunstan wrote: . how to turn it on for trusted plperl Eh, you don't turn it on. You install the package and it works ;) Really? If the plperl Safe opmask allows that, we've got some problems. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] DBD::PgSPI 0.02
On Mon, 6 Dec 2004, Tom Lane wrote: [EMAIL PROTECTED] writes: On Mon, 6 Dec 2004, Andrew Dunstan wrote: . how to turn it on for trusted plperl Eh, you don't turn it on. You install the package and it works ;) Really? If the plperl Safe opmask allows that, we've got some problems. Errr my bad. I keep confusing trusted/untrusted. It does not allow it, nor should it. The purpose of PgSPI is to write 'middleware' solutions in perl - the idea is that you can take a piece of existing client-side code and make a server-side stored procedure out of it in a minute without any changes to the code. For quick access from trusted code, spi_exec should just do fine. -alex ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [Testperf-general] Re: [HACKERS] 8.0beta5 results w/ dbt2
On Mon, 2004-12-06 at 17:43, Josh Berkus wrote: Mark, Ok, here are a series of three tests varying the bgwriter_delay at 1, 50, and 100: http://www.osdl.org/projects/dbt2dev/results/pgsql/bgwriter_delay/ Hmmm. Looks inconclusive. The differences between the runs are 0.3%, which is a margin of error by anyone's definition. Will have to develop better tests ... Josh is right - these are inconclusive. That usually means the other settings are still very sub-optimal. The graphs show the effect of checkpointing is still very large, so it looks like the bgwriter is ineffective. Varying bgwriter_maxpages upwards should take performance higher. -- Best Regards, Simon Riggs ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] DBD::PgSPI 0.02
[EMAIL PROTECTED] wrote: . DBD::PgSPI is covered by GPL, which means it can't be used in the core distribution of postgres - we'd have to reinvent it in a clean room fashion. Actually, its both GPL and Artistic license - identical to DBD::Pg (where most of the code is taken from). I don't think this needs to be in core distribution - much like DBD::Pg doesn't need to be there either... I disagree. The crucial difference is that DBD::Pg is a client side library and plperl is not. I would like all perl programmers to be able to use the same (or similar) idioms on both the client side and the server side. (Just as one can use JDBC idioms in PL/Java, iirc). So I want a DBI handle to be available in core plperl if possible. cheers andrew ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] DBD::PgSPI 0.02
On Mon, 6 Dec 2004, Andrew Dunstan wrote: I disagree. The crucial difference is that DBD::Pg is a client side library and plperl is not. I would like all perl programmers to be able to use the same (or similar) idioms on both the client side and the server side. (Just as one can use JDBC idioms in PL/Java, iirc). So I want a DBI handle to be available in core plperl if possible. Just like perl programmers need to download DBD::Pg to deal with Pg on client side, I don't see what's so wrong with them having to download DBD::PgSPI to deal with it on server side. Besides the fact is that they have to download DBI to get *anywhere* in the first place ;0 -alex ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] somebody working on: Prevent default re-use of sysids for dropped users and groups?
Hi Tom + *, Am 03.12.2004 um 23:58 schrieb Tom Lane: schmidtm [EMAIL PROTECTED] writes: is somebody working on these two issues on the TODO-List? 1) Prevent default re-use of sysids for dropped users and groups I don't know of anyone actively working on it, but if you check the archives you'll find that the preferred solution approach is pretty well hashed out --- it boils down to creating a shared sequence object and using that, rather than a MAX(sysid) query, to select default sysids. The painful part of this is just that bootstrap mode doesn't currently have any support for creating sequences. I don't think fixing that will be hugely hard, but it might be a bit tedious. Do I get that right: the only reason to do max(sysid) or a user-supplied ID in CreateUser() (commands/user.c) is that we don't have the ability to get sequences over the *.BKI/initdb mechanism? If that is true and you think it's possible and worth to have sequences in the bootstrap, I volunteer to do this. 2) Prevent dropping user that still owns objects, or auto-drop the objects No one has any idea how to do this reasonably --- the problem is you have no visibility into databases other than the one you're connected to, so you can't tell what the user owns in other databases. I think it's much better to leave this to somebody with far more understanding of the subject. regards, tom lane cheers, Matthias -- Matthias Schmidt Viehtriftstr. 49 67346 Speyer Tel.: +49 6232 4867 Fax.: +49 6232 640089 ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] DBD::PgSPI 0.02
On Mon, Dec 06, 2004 at 02:34:33PM -0500, [EMAIL PROTECTED] wrote: For quick access from trusted code, spi_exec should just do fine. BTW, does stock PL/Perl have functions for escaping identifiers, strings, and binary strings? -- Michael Fuhr http://www.fuhr.org/~mfuhr/ ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] DBD::PgSPI 0.02
On Mon, 6 Dec 2004, Michael Fuhr wrote:
On Mon, Dec 06, 2004 at 02:34:33PM -0500, [EMAIL PROTECTED] wrote:
For quick access from trusted code, spi_exec should just do fine.
BTW, does stock PL/Perl have functions for escaping identifiers,
strings, and binary strings?
non-DBI? no.
DBI? yes, $pg_dbh-quote('foo')
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
Re: [HACKERS] DBD::PgSPI 0.02
On Mon, Dec 06, 2004 at 03:02:45PM -0500, [EMAIL PROTECTED] wrote:
On Mon, 6 Dec 2004, Michael Fuhr wrote:
On Mon, Dec 06, 2004 at 02:34:33PM -0500, [EMAIL PROTECTED] wrote:
For quick access from trusted code, spi_exec should just do fine.
BTW, does stock PL/Perl have functions for escaping identifiers,
strings, and binary strings?
non-DBI? no.
DBI? yes, $pg_dbh-quote('foo')
Yeah, I know about DBI, but since we currently can't use it in
trusted code I was wondering what we *could* use. With DBI I'd be
using placeholders wherever possible, but unless I've missed something
spi_exec_query() requires values to be interpolated into the query
string. Danger, danger.
--
Michael Fuhr
http://www.fuhr.org/~mfuhr/
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] DBD::PgSPI 0.02
Michael Fuhr wrote:
DBI? yes, $pg_dbh-quote('foo')
Yeah, I know about DBI, but since we currently can't use it in
trusted code I was wondering what we *could* use. With DBI I'd be
using placeholders wherever possible, but unless I've missed something
spi_exec_query() requires values to be interpolated into the query
string. Danger, danger.
One of the relatively unnoticed features of 8.0's plperl is %_SHARED.
This is a hash available to all trusted and untrusted code, and can be
used to store arbitrary objects. That includes references to
subroutines. So you could have an init function that you call once per
session that sets up some utility functions for you and stores them
there. Writing a quote function shuld not be too hard. (Some
automatically called init code is another item on the plperl agenda.)
moderately tested example:
-- set up the quote function
CREATE OR REPLACE FUNCTION myfuncs() RETURNS void LANGUAGE plperl AS $$
$_SHARED{myquote} = sub
{
my $arg = shift;
$arg =~ s/(['\\])/\\$1/g;
return '$arg';
};
$$;
SELECT myfuncs();
-- set up a function that uses the quote function
CREATE OR REPLACE FUNCTION use_quote(text) RETURNS text LANGUAGE plperl AS $$
my $text_to_quote = shift;
my $qfunc = $_SHARED{myquote};
return $qfunc($text_to_quote);
$$;
SELECT use_quote($$bl\ur'fl$$);
cheers
andrew
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
Re: [HACKERS] WIN1252 encoding - backend or not?
On Sun, Dec 05, 2004 at 04:06:57PM -0500, Andrew Dunstan wrote: Amen, brother! That would never be tolerated in any commercial setting that I am aware of, and should not be here either, IMNSHO. Silence does I don't know what commercial settings you're familiar with, but I can think of some where it _would_ be tolerated. That toleration, however, certainly explains a number of really crappy pieces of software I've had to work with. A -- Andrew Sullivan | [EMAIL PROTECTED] A certain description of men are for getting out of debt, yet are against all taxes for raising money to pay it off. --Alexander Hamilton ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] WIN1252 encoding - backend or not?
On Mon, Dec 06, 2004 at 04:00:30PM -0500, Andrew Sullivan wrote: however, certainly explains a number of really crappy pieces of software I've had to work with. Uh, that's not a swipe at Bruce -- rather praise for everyone involved for being frank enough to discuss this. A -- Andrew Sullivan | [EMAIL PROTECTED] Information security isn't a technological problem. It's an economics problem. --Bruce Schneier ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] V8 Beta 5 on AIX
Bruce Momjian wrote:
Brad Nicholson wrote:
OK, I assume you used --enable-thread-safety in configure.
Correct.
This should
have added some PTHREAD link flags to your libpq build, and those
settings should have followed the libpq library into your pg_ctl link
line.
Would you look in your Makefile.global for PTHREAD_* settings and report
those. The second question is why saying those libraries are needed by
libpq is not passing down to uses of libpq, like in pg_ctl.
PTHREAD_CFLAGS =-pthread -D_REENTRANT -D_THREAD_SAFE
-D_POSIX_PTHREAD_SEMANTICS
PTHREAD_LIBS= -lpthread -lpthreads
OK, great. Can I see the link line that creates libpq? It should contain
the PTHREAD_LIBS flags.
I've attached the Makefile.global from the system, in case it's of use.
If it does, the next question is why AIX doesn't pass those flags.
Oh, I think I see the cause. I now remember from
config/acx_pthread.m4:
# More AIX lossage: must compile with cc_r
AC_CHECK_PROG(PTHREAD_CC, cc_r, cc_r, ${CC})
Seems AIX wants a special _compiler_ to be used whenever threading is
involved, even by a linked-in library. I didn't implement using
PTHREAD_CC because there was just too much code disruption for threading
on one platform. I wonder if we should just disable threading on AIX.
I believe that this will result in Slony not working on AIX.
Let me ask --- if you change the CC line in Makefile.global to cc_r,
does everything build OK? That might be a clean solution because the
change could be made in one place. Of course this would mean the
backend would also be compiled using cc_r and I have no idea of the
effect.
Not an option, we don't have cc_r on the server.
Of course, the idea that any use of libpq has to use cc_r is going to
make building things complex without some adjustments.
Also, what version of AIX are you using? Are other AIX folks having
thread build problems?
5.1
Brad.
# -*-makefile-*-
# $PostgreSQL: pgsql/src/Makefile.global.in,v 1.205 2004/11/19 00:41:38 tgl Exp
$
#--
# All PostgreSQL makefiles include this file and use the variables it sets,
# which in turn are put here by the configure script. There is no need for
# users to edit this file -- if it turns out to be necessary then that's a
# bug.
#
# A makefile that includes this file needs to set the variable `subdir' to
# the relative path from the top to itself and `top_builddir' to the relative
# path from itself to the top before including this file. (The top is the
# parent directory of the directory this file is in.)
#--
##
#
# Meta configuration
.PHONY: all install install-strip installdirs uninstall clean distclean
maintainer-clean distprep check installcheck maintainer-check
.SILENT: installdirs
# make `all' the default target
all:
# Delete target files if the command fails after it has
# started to update the file.
.DELETE_ON_ERROR:
# PostgreSQL version number
VERSION = 8.0.0rc1
# Support for VPATH builds
vpath_build = no
abs_top_srcdir = /opt/OXRS/Sources/pgsql-HEAD
ifneq ($(vpath_build),yes)
top_srcdir = $(top_builddir)
srcdir = .
else # vpath_build = yes
top_srcdir = $(abs_top_srcdir)
srcdir = $(top_srcdir)/$(subdir)
endif
# Saved arguments from configure
configure_args = '--prefix=/opt/dbs/pgsql800-beta5-AIX51-2004-12-06'
'--with-includes=/opt/OXRS/supporting-packages/readline-4.2/include:/opt/OXRS/supporting-packages/zlib-1.1.4/include'
'--enable-debug' '--enable-thread-safety'
'--with-libraries=/opt/OXRS/supporting-packages/readline-4.2/lib:/opt/OXRS/supporting-packages/zlib-1.1.4'
##
#
# Installation directories
#
# These are set by the equivalent --xxxdir configure options. We
# append postgresql to some of them, if the string does not already
# contain pgsql or postgres, in order to avoid directory clutter.
prefix := /opt/dbs/pgsql800-beta5-AIX51-2004-12-06
exec_prefix := ${prefix}
bindir := ${exec_prefix}/bin
sbindir := ${exec_prefix}/sbin
libexecdir := ${exec_prefix}/libexec
ifeq $(findstring pgsql, $(libexecdir))
ifeq $(findstring postgres, $(libexecdir))
override libexecdir := $(libexecdir)/postgresql
endif
endif
datadir := ${prefix}/share
ifeq $(findstring pgsql, $(datadir))
ifeq $(findstring postgres, $(datadir))
override datadir := $(datadir)/postgresql
endif
endif
sysconfdir := ${prefix}/etc
ifeq $(findstring pgsql, $(sysconfdir))
ifeq $(findstring postgres, $(sysconfdir))
override sysconfdir := $(sysconfdir)/postgresql
endif
endif
libdir := ${exec_prefix}/lib
pkglibdir = $(libdir)
ifeq $(findstring pgsql, $(pkglibdir))
ifeq $(findstring postgres, $(pkglibdir))
override pkglibdir := $(pkglibdir)/postgresql
endif
endif
includedir
Re: [Testperf-general] Re: [HACKERS] 8.0beta5 results w/ dbt2
On Mon, 2004-12-06 at 17:42, Mark Wong wrote: On Tue, Nov 30, 2004 at 10:51:42PM +, Simon Riggs wrote: My suggestion: increase checkpoint_timeout to 600 secs, increase bgwriter parameters also, to reduce how frequently it is called, as well as increase the number of blocks per cycle. Ok, here are a series of three tests varying the bgwriter_delay at 1, 50, and 100: http://www.osdl.org/projects/dbt2dev/results/pgsql/bgwriter_delay/ I also reduced checkpoint_timeout to 600, where it was prevously at 1800 with the results I posted previously. The throughput changes weren't significant and the oprofile data is more of less the same. I'll try varying the bgwriter_maxpages next (that's the number of blocks per cycle, right?) Mark, Few questions: - can we put the logging to DEBUG1 please, so we can see the checkpoints? ...and set debug_shared_buffers = 10 I don't understand why the checkpoints are so regular at 300 seconds if the checkpoint_timeout is set to 1800 or other...exactly when and how are those parameters provided to the server? - can we set checkpoint_segments to 8192 just to see if that changes the checkpoint frequency (it should) - the log output shows the database starts about 4 hours before the main test starts... err whats going on there? maybe we could get more tests in if that time could be reduced - the explain plan output is missing... http://www.osdl.org/projects/dbt2dev/results/dev4-010/199/db/plan0.out.gz - the log output shows deadlocks occurring - is there something about the application of DBT-2 which is actually causing contention? Might that have changed between beta4 and beta5? The earlier lock waits we saw (Exclusive Lock thread) are likely to be related to that. Is there some other artifact of the test that could cause this...random number generatoretc. My understanding was that TPC-C didn't deadlock, but I could be wrong there. This could easily be throwing off the test results... usually to do with the order in which locks are occurring... if its not, I hope its not a bug,,, -- Best Regards, Simon Riggs ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] V8 Beta 5 on AIX
On Mon, Dec 06, 2004 at 01:07:11PM -0500, Bruce Momjian wrote: I see now you are running AIX 5.1. Is that a fairly modern/popular version of AIX? To the extent AIX is popular :) 5.1 is one release behind the very latest. A -- Andrew Sullivan | [EMAIL PROTECTED] The plural of anecdote is not data. --Roger Brinner ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] DBD::PgSPI 0.02
[EMAIL PROTECTED] writes: On Mon, 6 Dec 2004, Andrew Dunstan wrote: . how to turn it on for trusted plperl [ snip ] Errr my bad. I keep confusing trusted/untrusted. It does not allow it, nor should it. The purpose of PgSPI is to write 'middleware' solutions in perl - the idea is that you can take a piece of existing client-side code and make a server-side stored procedure out of it in a minute without any changes to the code. Sure. But you don't run your middleware as root (I hope ;-)) and you shouldn't run it in untrusted server-side languages either. I agree with Andrew that it's important to figure out how to make DBI usable in trusted plperl. Obviously this isn't happening in time for 8.0, but it deserves a place on the TODO list. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] V8 Beta 5 on AIX
On Mon, 2004-12-06 at 21:59, Andrew Sullivan wrote: On Mon, Dec 06, 2004 at 01:07:11PM -0500, Bruce Momjian wrote: I see now you are running AIX 5.1. Is that a fairly modern/popular version of AIX? To the extent AIX is popular :) 5.1 is one release behind the very latest. AIX 5.3 is out now... AIX 5.1 is still fully supported though... -- Best Regards, Simon Riggs ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] DBD::PgSPI 0.02
On Mon, 6 Dec 2004, Tom Lane wrote: Sure. But you don't run your middleware as root (I hope ;-)) and you shouldn't run it in untrusted server-side languages either. I agree Actually - I don't practically care, and in fact I'm doing things that are unsafe...But, I agree, others may think differently ;) with Andrew that it's important to figure out how to make DBI usable in trusted plperl. Obviously this isn't happening in time for 8.0, but it deserves a place on the TODO list. It's interesting but its probably a untrivial effort to make DBI itself Safe-safe. Probably it would require starting with DBI::PurePerl (non-XS version) and adding a mode that would disable all unSafe activity (such as file operations etc etc)... -alex ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] somebody working on: Prevent default re-use of sysids for dropped users and groups?
schmidtm [EMAIL PROTECTED] writes: Do I get that right: the only reason to do max(sysid) or a user-supplied ID in CreateUser() (commands/user.c) is that we don't have the ability to get sequences over the *.BKI/initdb mechanism? No, that's not quite the direction of the problem. The real reason those facilities are there is so that you can deliberately create a user having a previously-used sysid. And the only reason why that is needed is that we don't have dependency tracking for references to users and groups. If you could be certain that there were no remaining references to a userid when it is dropped, there would be no need to be able to resurrect it. And that would mean that we could forget the whole sysid assignment mess and just use the regular OID generator to create unique IDs for users and groups. Using a shared sequence instead of max(sysid) would be merely an incremental improvement in the existing sysid assignment rules --- it wouldn't eliminate the entire kluge at one blow. So if Alvaro's thing works out, the shared-sequence problem becomes moot. Probably that's a good reason not to spend time on it just yet. regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
[HACKERS] branch for 8.0?
There was some talk of branching REL8_0_STABLE after 8.0.0rc1 was released. Is that still the plan? TIA, Neil ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [Testperf-general] Re: [HACKERS] 8.0beta5 results w/ dbt2
On Mon, Dec 06, 2004 at 09:28:15PM +, Simon Riggs wrote: Mark, Few questions: - can we put the logging to DEBUG1 please, so we can see the checkpoints? ...and set debug_shared_buffers = 10 Ok, will do. I don't understand why the checkpoints are so regular at 300 seconds if the checkpoint_timeout is set to 1800 or other...exactly when and how are those parameters provided to the server? I don't think I do either. I always set the parameters by editing the postgresql.conf file. - can we set checkpoint_segments to 8192 just to see if that changes the checkpoint frequency (it should) Ok. - the log output shows the database starts about 4 hours before the main test starts... err whats going on there? maybe we could get more tests in if that time could be reduced I start 5000 clients every 3 seconds. I tend to find if I start them too fast, my client tends to start dropping connections. Maybe a tcp/ip tuning problem between my client and driver. - the explain plan output is missing... http://www.osdl.org/projects/dbt2dev/results/dev4-010/199/db/plan0.out.gz Ugh, I really do mean to fix that... Something changed so it's not being captured at all. It really should be easy for me to fix. - the log output shows deadlocks occurring - is there something about the application of DBT-2 which is actually causing contention? Might that have changed between beta4 and beta5? The earlier lock waits we saw (Exclusive Lock thread) are likely to be related to that. Is there some other artifact of the test that could cause this...random number generatoretc. My understanding was that TPC-C didn't deadlock, but I could be wrong there. This could easily be throwing off the test results... usually to do with the order in which locks are occurring... if its not, I hope its not a bug,,, Nothing that I can think of. Each thread is initialized with a different random number seed so we shouldn't see any identicle transactions occuring because of that. Mark ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] V8 Beta 5 on AIX
Simon Riggs wrote: On Mon, 2004-12-06 at 21:59, Andrew Sullivan wrote: On Mon, Dec 06, 2004 at 01:07:11PM -0500, Bruce Momjian wrote: I see now you are running AIX 5.1. Is that a fairly modern/popular version of AIX? To the extent AIX is popular :) 5.1 is one release behind the very latest. AIX 5.3 is out now... AIX 5.1 is still fully supported though... OK, so does someone want to suggest why a library used to link libpq would also be needed to link binaries that use libpq? And with no cc_r it seems I have no idea how to get this working. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [Testperf-general] Re: [HACKERS] 8.0beta5 results w/ dbt2
On Mon, 2004-12-06 at 23:18, Mark Wong wrote: On Mon, Dec 06, 2004 at 09:28:15PM +, Simon Riggs wrote: Mark, Few questions: Thanks. On the graphs... why do the graphs for Proc Utilisation, Index Scans etc, only show first 300 secs of a 3600 sec long run? Are those axes correct? (I understand seeing the ramp-up is important, I just want to check the time axis). What do you think the periodicity is on those graphs that has an order of around 10 secs if that axis is correct? Thats about every 400 transactions. Anybody? -- Best Regards, Simon Riggs ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] V8 Beta 5 on AIX
Bruce Momjian [EMAIL PROTECTED] writes: OK, so does someone want to suggest why a library used to link libpq would also be needed to link binaries that use libpq? No doubt because it's one of those platforms where shared libraries don't carry their own dependency information. AFAICS, PTHREAD_LIBS is not propagated into the link lines of pg_ctl or any of the other programs that use libpq, so the only place where the linker would find out about it is if the info is embedded in libpq.so. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [Testperf-general] Re: [HACKERS] 8.0beta5 results w/ dbt2
On Mon, Dec 06, 2004 at 11:44:22PM +, Simon Riggs wrote: On the graphs... why do the graphs for Proc Utilisation, Index Scans etc, only show first 300 secs of a 3600 sec long run? Are those axes correct? (I understand seeing the ramp-up is important, I just want to check the time axis). What do you think the periodicity is on those graphs that has an order of around 10 secs if that axis is correct? Thats about every 400 transactions. Anybody? Whoops! Those are supposed to be minutes. The granularity of the intervals have always been 1 minute (60 seconds). I wonder why I put seconds on the charts... I'll fix that too. Mark ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
[HACKERS] Call for port reports
I have started filling in the supported platform list for the 8.0.0 release with the information from the build farm: http://developer.postgresql.org/docs/postgres/supported-platforms.html It's now time to fill the holes. Briefly, I'm looking for exit status 0 on ./configure --prefix=SOMEWHERE --enable-thread-safety --with-tcl \ --with-perl --with-python --with-krb5 --with-pam -with-openssl make make install make check with PostgreSQL 8.0.0rc1 or later. If you know what you're doing, you can also try other options, but please tell what you did. (I would like the build farm members for Windows and Cygwin to use more feature-enabling options, because in those cases we really need the information about which extra features compile and work.) If your system provides multiple compilers (for example, a vendor compiler and GCC), test with all of them. Call configure as follows: ./configure CC=/foo/cc --prefix=... If your system has multiple compilation modes, such as 32 bit and 64 bit, it may be worth trying both. Report the output of SELECT version(); as well as a common name of the operating system under which it can be listed (e.g., the distributor, in case of a Linux-based system). -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] V8 Beta 5 on AIX
Bruce Momjian wrote: OK, so does someone want to suggest why a library used to link libpq would also be needed to link binaries that use libpq? And with no cc_r it seems I have no idea how to get this working. We didn't get this working for 7.4, for reasons that we are again becoming aware of, so I don't think it's justifiable to try to fix it for 8.0 at this point. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] branch for 8.0?
Neil Conway [EMAIL PROTECTED] writes: There was some talk of branching REL8_0_STABLE after 8.0.0rc1 was released. Is that still the plan? I'm up for it, personally --- is everybody else ready? Should we wait another day or three? regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] apparent problem on linux/s390
headsup courtesy of buildfarm. problems apparently with NaNs, infinities and negative zeros. see: http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=fantaildt=2004-12-06%2011:05:24 cheers ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Call for port reports
Peter Eisentraut wrote: I have started filling in the supported platform list for the 8.0.0 release with the information from the build farm: http://developer.postgresql.org/docs/postgres/supported-platforms.html It's now time to fill the holes. Briefly, I'm looking for exit status 0 on ./configure --prefix=SOMEWHERE --enable-thread-safety --with-tcl \ --with-perl --with-python --with-krb5 --with-pam -with-openssl make make install make check buildfarm actually runs in this order: make make check make contrib make install ... more steps I assume that's ok. with PostgreSQL 8.0.0rc1 or later. If you know what you're doing, you can also try other options, but please tell what you did. (I would like the build farm members for Windows and Cygwin to use more feature-enabling options, because in those cases we really need the information about which extra features compile and work.) I will try. For Windows especially, it's possibly quite a deal of work - the client is running experimental code that is quite radically different from the released buildfarm code. Getting it to work with python, tcl, and openssl will be fun ... at any rate it will not be done by me for days. If anyone else (Magnus? Dave?) can supply this info for Windows I'd be glad. cheers andrew ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] V8 Beta 5 on AIX
On Mon, Dec 06, 2004 at 12:53:52PM -0500, Bruce Momjian wrote:
Brad Nicholson wrote:
OK, I assume you used --enable-thread-safety in configure.
Correct.
This should
have added some PTHREAD link flags to your libpq build, and those
settings should have followed the libpq library into your pg_ctl link
line.
Would you look in your Makefile.global for PTHREAD_* settings and report
those. The second question is why saying those libraries are needed by
libpq is not passing down to uses of libpq, like in pg_ctl.
PTHREAD_CFLAGS =-pthread -D_REENTRANT -D_THREAD_SAFE
-D_POSIX_PTHREAD_SEMANTICS
PTHREAD_LIBS= -lpthread -lpthreads
OK, great. Can I see the link line that creates libpq? It should contain
the PTHREAD_LIBS flags.
If it does, the next question is why AIX doesn't pass those flags.
Oh, I think I see the cause. I now remember from
config/acx_pthread.m4:
# More AIX lossage: must compile with cc_r
AC_CHECK_PROG(PTHREAD_CC, cc_r, cc_r, ${CC})
Seems AIX wants a special _compiler_ to be used whenever threading is
involved, even by a linked-in library. I didn't implement using
PTHREAD_CC because there was just too much code disruption for threading
on one platform. I wonder if we should just disable threading on AIX.
Let me ask --- if you change the CC line in Makefile.global to cc_r,
does everything build OK? That might be a clean solution because the
change could be made in one place. Of course this would mean the
backend would also be compiled using cc_r and I have no idea of the
effect.
Of course, the idea that any use of libpq has to use cc_r is going to
make building things complex without some adjustments.
Also, what version of AIX are you using? Are other AIX folks having
thread build problems?
We have until very recently supporting a number of applications
requiring threading on AIX 3/4/5. They always required much more
understanding of the entire compile/link/run cycle than any other
platform we use. Changing the CC line to cc_r works fine with the
only problem being the cascaded use of cc_r into any application
that links against libpq. Even with these complications, I think
we should still allow threading on AIX. Anyone who builds software
on AIX already knows how to manage these issues.
Ken
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] branch for 8.0?
On Mon, 6 Dec 2004, Tom Lane wrote: Neil Conway [EMAIL PROTECTED] writes: There was some talk of branching REL8_0_STABLE after 8.0.0rc1 was released. Is that still the plan? I'm up for it, personally --- is everybody else ready? Should we wait another day or three? Let's say Friday I branch her ... ? Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] V8 Beta 5 on AIX
Peter Eisentraut wrote: Bruce Momjian wrote: OK, so does someone want to suggest why a library used to link libpq would also be needed to link binaries that use libpq? And with no cc_r it seems I have no idea how to get this working. We didn't get this working for 7.4, for reasons that we are again becoming aware of, so I don't think it's justifiable to try to fix it for 8.0 at this point. Yea, we needed this problem report during beta, not RC. I added this to Makefile.unixware long ago: # Unixware needs threads for everything that uses libpq CFLAGS += $(PTHREAD_CFLAGS) I said if we found another platform that had a similar limitation we would fix it more thoroughly, but I needed to fix it earlier to get into 8.0. However, one thing we can do is to try this in Makefile.aix: # AIX needs threads for everything that uses libpq LIBS += $(PTHREAD_LIBS) That is going to enable thread libs for all linking including the backend, but it might work. Unixware found that doing this for the backend brought out threading OS bugs and it was useless but AIX might be better. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] V8 Beta 5 on AIX
Kenneth Marshall wrote: Let me ask --- if you change the CC line in Makefile.global to cc_r, does everything build OK? That might be a clean solution because the change could be made in one place. Of course this would mean the backend would also be compiled using cc_r and I have no idea of the effect. Of course, the idea that any use of libpq has to use cc_r is going to make building things complex without some adjustments. Also, what version of AIX are you using? Are other AIX folks having thread build problems? We have until very recently supporting a number of applications requiring threading on AIX 3/4/5. They always required much more understanding of the entire compile/link/run cycle than any other platform we use. Changing the CC line to cc_r works fine with the only problem being the cascaded use of cc_r into any application that links against libpq. Even with these complications, I think we should still allow threading on AIX. Anyone who builds software on AIX already knows how to manage these issues. OK, but why does the AIX 5.1 version they have not have cc_r? -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Call for port reports
Sorry, here is select version(); PostgreSQL 8.0.0rc1 on i386-pc-bsdi4.3.1, compiled by GCC 2.95.3 --- Peter Eisentraut wrote: I have started filling in the supported platform list for the 8.0.0 release with the information from the build farm: http://developer.postgresql.org/docs/postgres/supported-platforms.html It's now time to fill the holes. Briefly, I'm looking for exit status 0 on ./configure --prefix=SOMEWHERE --enable-thread-safety --with-tcl \ --with-perl --with-python --with-krb5 --with-pam -with-openssl make make install make check with PostgreSQL 8.0.0rc1 or later. If you know what you're doing, you can also try other options, but please tell what you did. (I would like the build farm members for Windows and Cygwin to use more feature-enabling options, because in those cases we really need the information about which extra features compile and work.) If your system provides multiple compilers (for example, a vendor compiler and GCC), test with all of them. Call configure as follows: ./configure CC=/foo/cc --prefix=... If your system has multiple compilation modes, such as 32 bit and 64 bit, it may be worth trying both. Report the output of SELECT version(); as well as a common name of the operating system under which it can be listed (e.g., the distributor, in case of a Linux-based system). -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Call for port reports
== All 96 tests passed. == version PostgreSQL 8.0.0rc1 on i386-unknown-freebsd5.3, compiled by GCC gcc (GCC) 3.4.2 [FreeBSD] 20040728 (1 row) Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] V8 Beta 5 on AIX
Bruce Momjian [EMAIL PROTECTED] writes: However, one thing we can do is to try this in Makefile.aix: # AIX needs threads for everything that uses libpq LIBS += $(PTHREAD_LIBS) That is going to enable thread libs for all linking including the backend, but it might work. That is certainly wrong. The correct thing is to add PTHREAD_LIBS to all and only those links that include libpq. I suspect that the cc_r business is a red herring and the real problem is just that you forgot to include the libraries --- if so, AIX is probably not the only platform that will break. regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Call for port reports
Andrew Dunstan [EMAIL PROTECTED] writes: Peter Eisentraut wrote: ./configure --prefix=SOMEWHERE --enable-thread-safety --with-tcl \ --with-perl --with-python --with-krb5 --with-pam -with-openssl make make install make check buildfarm actually runs in this order: make make check make contrib make install ... more steps I assume that's ok. There is a difference, which is that on some (most?) platforms the latter sequence will involve make check invoking the libpq shared library that was installed by the previous iteration of make install. I'm not sure that this matters a whole lot for the buildfarm, since at worst it would result in failures for one test cycle when libpq.so changes incompatibly. But it's important to realize what you are testing. regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
[HACKERS] how can i add my own procedural language?
hi is Procedural language handler function the interface for adding your own procedural languages to postgres? I ve read the documentation but i am not able to understand where do we deal with stuff like parse trees, query trees, plan trees etc. Ofcourse any procedural language should pass through all the steps ie parsing, planning/optimization and execution. so where do we define these steps? and what interface is provided by postgresql? thank you __ Do you Yahoo!? Take Yahoo! Mail with you! Get it on your mobile phone. http://mobile.yahoo.com/maildemo ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] how can i add my own procedural language?
Sibtay, hi is Procedural language handler function the interface for adding your own procedural languages to postgres? I ve read the documentation but i am not able to understand where do we deal with stuff like parse trees, query trees, plan trees etc. Ofcourse any procedural language should pass through all the steps ie parsing, planning/optimization and execution. so where do we define these steps? and what interface is provided by postgresql? You normally don't deal with parsing, planning etc. at all from within a language handler. If you want to know how to issue a SQL query from within a function, a good start is to look at the Server Programming Interface (SPI) . The functions described there are normally the ones your language handler will use to access the database from within the function. http://www.postgresql.org/docs/7.4/interactive/spi.html Take a look at the code for the languages that are bundled with PostgreSQL. In the source tree, you will find them under src/pl. The pltcl.c was very helpful to me when I first did this. Other links where you will find source that might be helpful: http://pgfoundry.org/projects/plperlng http://gborg.postgresql.org/project/pljava Regards, Thomas Hallgren ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Call for port reports
Tom Lane said: Andrew Dunstan [EMAIL PROTECTED] writes: Peter Eisentraut wrote: ./configure --prefix=SOMEWHERE --enable-thread-safety --with-tcl \ --with-perl --with-python --with-krb5 --with-pam -with-openssl make make install make check buildfarm actually runs in this order: make make check make contrib make install ... more steps I assume that's ok. There is a difference, which is that on some (most?) platforms the latter sequence will involve make check invoking the libpq shared library that was installed by the previous iteration of make install. I'm not sure that this matters a whole lot for the buildfarm, since at worst it would result in failures for one test cycle when libpq.so changes incompatibly. But it's important to realize what you are testing. The script installs to a non-standard location ( buildroot/branch/inst ) and removes the installation at the end of each run. In fact, it refuses to run if this directory exists when the run starts, precisely so we don't get clobbered by previous runs. Also, note that since it stops on the first step that fails, the failure would persist rather than lasting one cycle, had we not prevented it in the first place. cheers andrew ---(end of broadcast)--- TIP 8: explain analyze is your friend
[HACKERS] spi and other languages
i guess the answer to my previous question was spi...i ve got another question, can we call pgsql or plpgsql functions using spi? like can we do something like SPI_execute(CREATE FUNCTION blah() RETURNS Integer . __ Do you Yahoo!? All your favorites on one personal page Try My Yahoo! http://my.yahoo.com ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
