[HACKERS] unsubscribe
unsubscribe -- Wade Klaver Wavefire Technologies Corporation GPG Public Key at http://archeron.wavefire.com /"\ ASCII Ribbon Campaign . \ / - NO HTML/RTF in e-mail . X - NO Word docs in e-mail . / \ - ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Initdb segfaults during "initializing pg_authid"
Looks like the distclean may have done it. I thought I had already, but who knows. Thanks. -Wade On Tuesday 20 June 2006 09:51, Tom Lane wrote: > Wade Klaver <[EMAIL PROTECTED]> writes: > > Initdb seems to barf on me during the pg_authid bit. Below are the > > specifics. Please ask if you need anything else. The build is CVS -HEAD. > > Are you sure it's a clean build? "make distclean" and trying again is > often the first thing to try when seeing unexpected problems with a CVS > pull. > > If that doesn't help, please try it with --enable-debug --enable-cassert > so we can get more info. > > regards, tom lane -- Wade Klaver Wavefire Technologies Corporation GPG Public Key at http://archeron.wavefire.com /"\ ASCII Ribbon Campaign . \ / - NO HTML/RTF in e-mail . X - NO Word docs in e-mail . / \ - ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
[HACKERS] Initdb segfaults during "initializing pg_authid"
Hello folks, Initdb seems to barf on me during the pg_authid bit. Below are the specifics. Please ask if you need anything else. The build is CVS -HEAD. Initdb output: [EMAIL PROTECTED]:bin/initdb The files belonging to this database system will be owned by user "pgsql". This user must also own the server process. The database cluster will be initialized with locale C. creating directory /usr/local/pgsql/data ... ok creating subdirectories ... ok selecting default max_connections ... 100 selecting default shared_buffers/max_fsm_pages ... 3500/175000 creating configuration files ... ok creating template1 database in /usr/local/pgsql/data/base/1 ... ok initializing pg_authid ... Segmentation fault (core dumped) child process exited with exit code 139 initdb: removing data directory "/usr/local/pgsql/data" [EMAIL PROTECTED]:uname -a FreeBSD arch.wavefire.com 6.0-STABLE FreeBSD 6.0-STABLE #0: Thu Nov 3 10:59:55 PST 2005 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/WORKSTATION-5.0-SMP i386 (gdb) bt #0 0x080bb086 in FuncnameGetCandidates () #1 0x080e08d6 in LookupFuncName () #2 0x0810ebf3 in CreateTrigger () #3 0x08197c57 in PortalRunUtility () #4 0x081981ad in PortalRun () #5 0x08194306 in exec_simple_query () #6 0x08196394 in PostgresMain () #7 0x0813c908 in main () -- Wade Klaver Wavefire Technologies Corporation GPG Public Key at http://archeron.wavefire.com /"\ ASCII Ribbon Campaign . \ / - NO HTML/RTF in e-mail . X - NO Word docs in e-mail . / \ - ---(end of broadcast)--- TIP 1: 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] Make failed in HEAD with make -j
Hello folks, Not sure how critical this is, but I ran in to a problem building a fresh checkout of HEAD with 'make -j 6 all'. Below is the system CV plus the final seconds from the black box. Everything worked fine rerunning make with no -j switch. Thanks, and everyone have a great weekend, eh? -Wade Klaver [EMAIL PROTECTED] data]# uname -a FreeBSD ..com 5.2-CURRENT FreeBSD 5.2-CURRENT #22: Mon Feb 2 13:54:43 PST 2004 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/WORKSTATION-5.0-SMP i386 [EMAIL PROTECTED] data]# gmake --version GNU Make 3.80 [EMAIL PROTECTED] data]# gcc -v Using built-in specs. Configured with: FreeBSD/i386 system compiler Thread model: posix gcc version 3.3.3 [FreeBSD] 20031106 gcc -O2 -fno-strict-aliasing -Wall -Wmissing-prototypes -Wmissing-declarations - I../../../src/interfaces/libpq -I../../../src/include -DBINDIR=\"/usr/local/pgs ql/bin\" -c -o dumputils.o dumputils.c gcc -O2 -fno-strict-aliasing -Wall -Wmissing-prototypes -Wmissing-declarations - I../../../src/interfaces/libpq -I../../../src/include -DBINDIR=\"/usr/local/pgs ql/bin\" -c -o pg_restore.o pg_restore.c gcc -O2 -fno-strict-aliasing -Wall -Wmissing-prototypes -Wmissing-declarations - I../../../src/interfaces/libpq -I../../../src/include -DBINDIR=\"/usr/local/pgs ql/bin\" -c -o pg_dumpall.o pg_dumpall.c gcc -O2 -fno-strict-aliasing -Wall -Wmissing-prototypes -Wmissing-declarations p g_dumpall.o dumputils.o ../../../src/backend/parser/keywords.o -L../../../src/in terfaces/libpq -lpq -L../../../src/port -R/usr/local/pgsql/lib -lz -lreadline - lcrypt -lcompat -lm -lutil -lpgport -o pg_dumpall gcc: dumputils.o: No such file or directory gmake[3]: *** [pg_dumpall] Error 1 gmake[3]: *** Waiting for unfinished jobs gmake[3]: Leaving directory `/usr/local/src/pgsql7.5/src/bin/pg_dump' gmake[2]: *** [all] Error 2 gmake[2]: Leaving directory `/usr/local/src/pgsql7.5/src/bin' gmake[1]: *** [all] Error 2 gmake[1]: Leaving directory `/usr/local/src/pgsql7.5/src' gmake: *** [all] Error 2 *** Error code 2 1 error [EMAIL PROTECTED] pgsql7.5]# gmake all -- Wade Klaver Wavefire Technologies Corporation GPG Public Key at http://archeron.wavefire.com /"\ ASCII Ribbon Campaign . \ / - NO HTML/RTF in e-mail . X - NO Word docs in e-mail . / \ - ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] invalid tid errors in latest 7.3.4 stable.
Hello, Naturally, as I found this problem in a production database running 7.3.4, a back-patch to 7.3 would be desireable. Even if just a patch was available and was not commited to -STABLE, this would do. I would also then be able to test such a critter on our development server for a future back-port if that ever comes to pass. -Wade > I've committed the attached patch into CVS HEAD. I am now wondering > whether to back-patch it to the 7.3 branch or not. It's a bit larger > than I would have liked, and really needs more testing before being > shoved into a stable branch. > > AFAICT you need a minimum of two levels of triggers invoked by an RI > trigger to make this happen, so it may be a corner case best left > unfixed in the 7.3 branch. > > Opinions anyone? > > regards, tom lane -- Wade Klaver Wavefire Technologies Corporation GPG Public Key at http://archeron.wavefire.com /"\ ASCII Ribbon Campaign . \ / - NO HTML/RTF in e-mail . X - NO Word docs in e-mail . / \ - ---(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] invalid tid errors in latest 7.3.4 stable.
Hello Tom, In trying to come up with a test scenario, I loaded this db into a 7.4 db and got a similar message. It shows up as follows: dropsites=> begin; BEGIN dropsites=> delete from te_users where reseller = 21; ERROR: attempted to mark4update invisible tuple CONTEXT: PL/pgSQL function "c_delete_categories" line 14 at SQL statement dropsites=> Is this the same message using the new error reporting framework? -Wade On September 23, 2003 09:44 pm, Tom Lane wrote: > Wade Klaver <[EMAIL PROTECTED]> writes: > > Stumbled across an odd problem while cleaning data out of a database. I > > am getting these "invalid tid" errors. I tried the upgrade from 7.3.2 to > > 7.3.4. > > Hm. We fixed something with a similar symptom as of 7.3.3: > http://archives.postgresql.org/pgsql-hackers/2003-03/msg01099.php > If you are still seeing it in 7.3.4 then maybe there's another related > problem. Could you work up a self-contained test case? > > regards, tom lane > > ---(end of broadcast)--- > TIP 6: Have you searched our list archives? > >http://archives.postgresql.org -- Wade Klaver Wavefire Technologies Corporation GPG Public Key at http://archeron.wavefire.com /"\ ASCII Ribbon Campaign . \ / - NO HTML/RTF in e-mail . X - NO Word docs in e-mail . / \ - ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] invalid tid errors in latest 7.3.4 stable.
Hello folks,
Stumbled across an odd problem while cleaning data out of a database. I am
getting these "invalid tid" errors. I tried the upgrade from 7.3.2 to 7.3.4.
I tried a dumpall/initdb/restore... nadda. Nothing really usefull is coming
from the logs either, even though logging is cranked up. If anyone can
suggest a method to track down the cause of the following dialog with the db,
I would greatly appreciate it. If you need any more info, please just ask.
Thank you in advance.
-Wade
version
-
PostgreSQL 7.3.4 on i386-unknown-freebsd4.6, compiled by GCC 2.95.4
(-STABLE cvs from today)
dropsites=# begin;
BEGIN
dropsites=# delete from te_users where id = 954;
WARNING: Error occurred while executing PL/pgSQL function c_delete_categories
WARNING: line 14 at SQL statement
ERROR: heap_mark4update: (am)invalid tid
dropsites=# rollback;
ROLLBACK
Table "public.te_users"
Column |Type |
Modifiers
---+-+-
id| integer | not null default
nextval('"te_users_id_seq"'::text)
username | text| not null
password | text|
reseller | integer | not null default 0
directory | text|
contact | integer |
creation_date | timestamp with time zone| default now()
active| boolean | not null default 'f'
domain| integer | not null default 0
has_domain| boolean | not null default 'f'
tutorial_type | integer | default -1
tutorial_step | integer | default -1
license_agreement | boolean | default 'f'
use_header| integer | default 0
promo | boolean | not null default 'f'
last_billed | timestamp without time zone | default now()
Indexes: primary_fk primary key btree (username, "domain"),
te_users_id_key unique btree (id),
te_users_username_lower_idx btree (lower(username))
dropsites=# \d c_categories
Table "public.c_categories"
Column| Type | Modifiers
-+-+--
id | integer | not null default
nextval('public.c_categories_id_seq'::text)
category| integer | not null default 0
userid | integer | not null
form| integer | not null
name| text|
description | text|
lft | integer |
rgt | integer |
level | integer |
parentid| integer |
Indexes: c_categories_id_key unique btree (id)
Foreign Key constraints: $1 FOREIGN KEY (userid) REFERENCES te_users(id) ON
UPDATE NO ACTION ON DELETE CASCADE,
$2 FOREIGN KEY (form) REFERENCES c_forms(id) ON
UPDATE NO ACTION ON DELETE CASCADE,
c_categories_fk FOREIGN KEY (parentid) REFERENCES
c_categories(id) ON UPDATE NO ACTION ON DELETE SET DEFAULT,
c_categories_cat_fk FOREIGN KEY (category) REFERENCES
c_categories(id) ON UPDATE NO ACTION ON DELETE NO ACTION
--- Source of c_delete_categories ---
CREATE OR REPLACE FUNCTION c_delete_categories() returns TRIGGER AS '
begin
IF c_category_mutex() THEN
-- delete entry
DELETE FROM c_categories WHERE ID = old.id;
IF (old.rgt - old.lft) > 1 THEN
-- update children
UPDATE c_categories SET ParentID = old.parentid WHERE ParentID =
old.id;
UPDATE c_categories SET lft = lft - 1, rgt = rgt - 1, level = level -
1 WHERE lf
t > old.lft AND lft < old.rgt;
END IF;
-- remove extra space
UPDATE c_categories SET lft = lft - 2 WHERE lft > old.rgt;
UPDATE c_categories SET rgt = rgt - 2 WHERE rgt > old.rgt;
PERFORM c_category_clear_mutex();
return NULL;
else
return old;
END IF;
end;
' language 'plpgsql';
--- source of c_category_mutex ---
CREATE OR REPLACE FUNCTION c_category_mutex() returns BOOL AS '
DECLARE
mutex_count integer;
BEGIN
SELECT INTO mutex_count COUNT(*) FROM pg_class c, pg_attribute a
WHERE a.attrelid = c.oid
AND c.relname = ''___c_category_mutex___''
AND a.attname = ''___c_category_mutex___''
Re: [HACKERS] POSIX regex performance bug in 7.3 Vs. 7.2
Confirmed. Looks like a 100-fold increase. Thanx guys. Explain output can be seen here: http://arch.wavefire.com/pgregex.txt -Wade Klaver At 09:59 AM 2/5/03 -0500, Tom Lane wrote: >Tatsuo Ishii <[EMAIL PROTECTED]> writes: >> Ok. The original complain can be sasily solved at least for single >> byte encoding databases. With the small patches(against 7.3.1) >> included, I got following result. > >Nice work, Tatsuo! Wade, can you confirm that this patch solves your >problem? > >Tatsuo, please commit into REL7_3 branch only --- I'm nearly ready to do >a wholesale replacement of the regex code in HEAD, so you wouldn't >accomplish much except to create a merge problem for me ... > > regards, tom lane > > ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] POSIX regex performance bug in 7.3 Vs. 7.2
OK, I redid my trials with the same data set on 7.2.3 --with-multibyte and I get the same brutal performance hit, so it is definitely a multibyte-specific problem. WRT the distribution of the data in the table, I used the following: All g-words in /usr/share/dict with different processes attached: no process init caps. word || row_id etc... There are only about 1000 words that appear more than once (2 or 3 times) in 27k rows. -Wade Klaver At 11:08 PM 2/3/03 -0500, Tom Lane wrote: >Next question: may I guess that you weren't using MULTIBYTE in 7.2? > >After still more digging, I'm coming round to the opinion that the >problem is that MULTIBYTE is forced on in 7.3, and this imposes a >factor-of-256 overhead in a bunch of the operations in regcomp.c. >In particular, compiling a case-independent regex is now hugely >more expensive than it used to be. > >The parties who wanted to force MULTIBYTE on promised that there >would be no such penalties :-( > > regards, tom lane > > ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] POSIX regex performance bug in 7.3 Vs. 7.2
Well, IMHO I would rather see a delay of the roll-out by a day or two than see a release with such a serious performance glitch. Especially since I personally have been shooting my big mouth off to all my geek friends on the leaps and bounds PG has made in the last few releases. With my luck one of them will find it. :) I guess in the end, it comes down to the rest of you developer types, but I would be inclined to re-wrap. However, this is easy for me to say given that I have no idea how much work it actually is to re-wrap. -Wade Klaver At 08:07 PM 2/3/03 -0500, Tom Lane wrote: >Sigh. It seems that somebody broke caching of compiled regexes, >so that your regex is recompiled each time it's used. I haven't >dug into the logic yet, but I think it must have been a mistake >in Thomas' change to make the regex cache be searched circularly: > >2002-06-14 22:49 thomas > > * src/backend/utils/adt/regexp.c: Search the existing regular > expression cache as a ring buffer. Will optimize the case for > repeated calls for the same expression, which seems to be the most > common case. Formerly, always searched from the first entry. May > want to look at the least-recently-used algorithm to make sure it > is identifying the right slots to reclaim. Seems silly to do math > when it seems that we could simply use an incrementing counter... > >Considering that we now know that this is a factor-of-150 performance >hit, I wonder if this is a "must fix" for 7.3.2? We already wrapped >the tarball, but ... > > regards, tom lane > > ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] POSIX regex performance bug in 7.3 Vs. 7.2
At 05:51 PM 2/3/03 -0500, Tom Lane wrote: >wade <[EMAIL PROTECTED]> writes: >> Here is the profile information. I included a log of the session that >> generated it at the top of the gprof output. If there is any other info I >> can help you with, please let me know. > >A four-second test isn't long enough to gather any statistically >meaningful profile info. On most machines, gprof samples 100 times per >second, so realistically you need a minute or two of runtime to have >trustworthy numbers. > >Please replicate the rows in the table by a factor of ten or twenty or >so and try again. > > regards, tom lane OK, here goes again. I have tried a different table, this one with 27444 rows. In this case, the query with the regex of the form "row ~* 'regex'" runs in 1.113 seconds and the other runs in 600. The session idled for a while after the query completed if that makes a difference. Queries and explain output are included at the top of the gprof output. http://arch.wavefire.com/pgregexgmon.txt -Wade Klaver ---(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] POSIX regex performance bug in 7.3 Vs. 7.2
At 10:52 PM 1/31/03 -0500, Tom Lane wrote: >wade <[EMAIL PROTECTED]> writes: >> We recently upgraded a project from 7.2 to 7.3.1 to make use of some of >> the cool new features in 7.3. The installed version is CVS stable from >> yesterday. However, we noticed a major performance hit in POSIX regular >> expression matches against columns using the ~* operator. > >The only thought that comes to mind is that multibyte character sets are >supported in 7.3 whereas they were optional (and not default) in 7.2. >I'd not have expected a factor-of-150 performance hit from that, though. > >Could you rebuild your backend with profiling enabled and get a gprof >summary of where the time is going? > > regards, tom lane > > Here is the profile information. I included a log of the session that generated it at the top of the gprof output. If there is any other info I can help you with, please let me know. http://arch.wavefire.com/pgregexgmon.txt -Wade Klaver ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] POSIX regex performance bug in 7.3 Vs. 7.2
At 08:31 PM 2/1/03 +0800, Christopher Kings-Lynne wrote: >Why on earth are you using a CVS version!?!?!?! > >Chris > This problem manifests itself under 7.3.1 release as well. CVS is used so we can access patches to the SRF stuff implemented after 7.3.1 was released. Tom... any links that document the procedure for obtaining the profile information you requested? I've used a profiler briefly, but am not sure how to go about gathering information pertainent to this problematic query only. -Wade Klaver. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] POSIX regex performance bug in 7.3 Vs. 7.2
Hello, We recently upgraded a project from 7.2 to 7.3.1 to make use of some of the cool new features in 7.3. The installed version is CVS stable from yesterday. However, we noticed a major performance hit in POSIX regular expression matches against columns using the ~* operator. http://arch.wavefire.com/badregex73.txt has explain analyze output from 7.2 and 7.3.1 respectively. Both of these tables have only 101 rows. The 7.3.1 install is using the default settings from postgresql.conf. Any ideas as to why this should be happening? Should anyone require additional information, please let me know. -Wade Klaver ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[HACKERS] invalid tid errors.
Hello, Using Postgresql 7.3 (CVS REL7_3_STABLE today), I received the following error: dropsites=> delete from cart_stores; ERROR: heap_update: (am)invalid tid This came from a database that was dumped from 7.2.1 using 7.2.1's pg_dump and imported into 7.3. I was able to delete the rows individually with a where clause ( WHERE id = ... ). The problem attempting to delete all rows persisted even when there was only 1 row left, even though this last row deleted fine when I specified it explicitly with a where clause. I was able to delete the contents of other tables in the db without incident. I was also able to reproduce this on a second box, also CVS REL7_3_STABLE from about a week ago. This problem is not exhibited under 7.2.1. So, the question is, how do I go about tracking this down? Has anyone seen this? It was suggested by one person that memory may be the issue, but the fact that it is exhibited on two boxen makes that seem unlikely. FYI: Machine 1: PIII 600 w/ 256MB FreeBSD 4.6 STABLE Machine 2: Dual PIII 600 w/ 512MB FreeBSD 4.7 STABLE Thanx in advance. -Wade Klaver ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Query performance. 7.2.3 Vs. 7.3
At 09:58 PM 11/28/02 -0500, you wrote: >Hm. Are we sure that both versions were built with the same >optimization level, etc? (My private bet is that Wade's 7.2 didn't >have multibyte or locale support --- but that's a long shot when we >don't know the datatypes of the columns being joined on...) > >> Also, is it expected that the cardinality estimates for join steps won't >> be very accurate, right? (estimated: 19 rows, actual: 765 rows) OK, I've updated the link http://arch.wavefire.com/72v73a.txt to include the table schema for those involved in the query. As far as locale suport et al, I can tell you that both are built using a straigh, out-of-the-box ./configure. > >Well, it'd be nice to do better --- I was hoping Wade would look into >why the row estimates were off so much. I'd love to :). But where to start? Can you point me at a thread where a similar procedure was explained to someone else? -Wade > > regards, tom lane > >---(end of broadcast)--- >TIP 4: Don't 'kill -9' the postmaster > > ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] Query performance. 7.2.3 Vs. 7.3
While playing with one of my DBs under 7.3 to make use of its better explain features, I came across a query that runs significantly slower under 7.3 than 7.2.3. At first, I thought it would be a hardware issue, so i installed both versions on the same box. 7.2.3 tends to run the query in 80% of the time 7.3 does. Explain output can be found at http://arch.wavefire.com/72v73a.txt Please don't hesitate to drop me a line if you require more info. -Wade Klaver ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] (libpq) PQclear on questionable result pointer.
Greets all,
While attempting to clean up some memory leaks, I have encountered some
difficulties. In the code for PQclear() we have the check:
if (!res)
return;
The problem arrises when the result object pointer you are passing to clear
contains not a null and not a valid result object address, but a junk pointer.
PQclear() seg faults when the address is outside of the data segment.
(libpq bug?)
My question is, how does one determine when a PGresult* contains the address
of a valid result object? Rewriting the calling code is not an option sadly.
What I would like to be able to do is something like this:
if ( result_is_valid( res ) )
{
PQclear( res );
}
Thanks in advance for any help/suggestions.
-Wade
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [GENERAL] No postgres on Solaris
I found it in the PostgreSQL Administrator manual under "Managing Kernel Resources". Wade Oberpriller > > Hi, > I have been using Postgres-7.0.2 on Solaris 8 for the past few months, and > was about to upgrade to 7.1-test, and after following carefully the docs, I > get this: > > postgres@ultra31:~ > /usr/local/pgsql/bin/postmaster -D /usr/local/pgsql/data > IpcSemaphoreCreate: semget(key=5432004, num=17, 03600) failed: No space left > on > device > > This error does *not* mean that you have run out of disk space. > > It occurs either because system limit for the maximum number of > semaphore sets (SEMMNI), or the system wide maximum number of > semaphores (SEMMNS), would be exceeded. You need to raise the > respective kernel parameter. Look into the PostgreSQL documentation > for details. > > postgres@ultra31:~ > > > I looked at the FAQ_Solaris, but found nothing on this case. I remember > making changes to the kernel parameters when I fist installed postgres, but > can't remember where I found that info. > > Any clues? > > -- > System Administration: It's a dirty job, > but someone told I had to do it. > - > Martín Marquésemail: [EMAIL PROTECTED] > Santa Fe - Argentina http://math.unl.edu.ar/~martin/ > Administrador de sistemas en math.unl.edu.ar > - >
[HACKERS] PL/Perl on Solaris
Hello, I posted this message on pgsql-general, but didn't get a lot of feedback. I am running into problems using PL/Perl on Solaris 2.5.1. I have PostgreSQL v7.0.2, Perl v 5.005_03 (built as a shared library), and am using gcc v2.7.2.2 to compile all of the source. I include the paths to libperl.so and plperl.so in my LD_LIBRARY_PATH environment variable. I can create the plperl language and create functions that are defined as using plperl. When I attempt to execute the fundtion the postgres server crashes with a status of 11. If anybody has any clues, hints, previous experiences about this scenario, your help would be greatly appreciated. Wade Oberpriller StorageTek [EMAIL PROTECTED]
