On Tue, Jul 05, 2005 at 09:54:52PM +0200, Hans-Jürgen Schönig wrote:
How current is your checkout? Mine's from this morning and I don't
get a crash with the example you posted:

test=> SELECT func();
NOTICE: sql: SELECT 10, 10 FROM pg_locks WHERE transaction IS NOT NULL AND pid = pg_backend_pid()
func
------
0
(1 row)

Have you run "make distclean" and then done a fresh build?

--
Michael Fuhr
http://www.fuhr.org/~mfuhr/

---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

Michael Fuhr <mike (AT) fuhr (DOT) org> writes:
None for me either (trying on a Fedora Core 3 x86 box; don't currently
have plperl built on my other machine). Platform-specific issue maybe?

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo (AT) postgresql (DOT) org so that your
message can get through to the mailing list cleanly

On Tue, Jul 05, 2005 at 04:37:05PM -0400, Tom Lane wrote:
My platform that works is Solaris 9/sparc with Perl 5.8.7; compiler
is gcc 3.4.2.

Did you get a core dump? If so, can you do a stack trace on it?

--
Michael Fuhr
http://www.fuhr.org/~mfuhr/

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

On Tue, Jul 05, 2005 at 10:49:54PM +0200, Hans-Jürgen Schönig wrote:
Just to be sure: where are you looking? I don't know if it's
configurable on your platform, but I usually find core dumps under
$PGDATA/base/<databaseoid>/. Do you have a resource limit or other
setting that would prevent core dumps from happening? Tom Lane can
probably help out on that platform.

Can you run the query in psql? What about in a PL/pgSQL function?

--
Michael Fuhr
http://www.fuhr.org/~mfuhr/

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to majordomo (AT) postgresql (DOT) org)

Michael Fuhr <mike (AT) fuhr (DOT) org> writes:
CVS tip of the last forty-eight hours or so would dump into $PGDATA
instead. It's a good bet though that "ulimit -c" is set to 0 (no dumps)
by default on that platform. I tend to put
ulimit -c unlimited
into the postmaster startup script on Linux machines, so that I can get
core dumps.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

Has this been fixed?

---------------------------------------------------------------------------

Hans-Jürgen Schönig wrote:
--
Bruce Momjian | http://candle.pha.pa.us
pgman (AT) candle (DOT) pha.pa.us | (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: don't forget to increase your free space map settings

On Fri, Jul 29, 2005 at 10:46:35PM -0400, Bruce Momjian wrote:
I don't think anybody was able to reproduce the problem, and
Hans-Jürgen said that it started working after he rebooted
the box:

http://archives.postgresql.org/pgsql...7/msg00062.php

There was reportedly no core dump and apparently the reboot destroyed
whatever conditions were causing the problem, so it might be difficult
to find out what was happening :-(

Hans-Jürgen, did this problem ever reappear?

Somebody else recently reported a backend crash when calling PL/Perl
in 8.0.3, but again we've been given no core dump info and thus far
nobody has been able to duplicate the problem:

http://archives.postgresql.org/pgsql...7/msg00181.php

--
Michael Fuhr
http://www.fuhr.org/~mfuhr/

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

On Sat, Jul 30, 2005 at 02:43:23PM +0200, Hans-Jürgen Schönig wrote:
Are you saying that it *did* dump core, or that it *didn't*? It's
possible that your coredumpsize resource limit prevented a core
dump from happening at all. If you're playing with the development
code than it would be a good idea to set that limit so that you do
get core dumps. Configuring with --enable-debug and --enable-cassert
would also be useful, if you aren't doing so already.

....but unfortunate for finding out what was happening :-(

Had you stopped and restarted the postmaster before the reboot?
That is, was the reboot really necessary to "fix" the problem?
Had you run "make install" while the postmaster was still running?
I haven't tested whether that could cause a problem, but I wonder
if that's possible.

--
Michael Fuhr
http://www.fuhr.org/~mfuhr/

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

On Sat, Jul 30, 2005 at 03:46:46PM +0200, Hans-Jürgen Schönig wrote:
So were you able to get a stack trace from the core dump?

--
Michael Fuhr
http://www.fuhr.org/~mfuhr/

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

[Please copy the mailing list on replies.]

On Sat, Jul 30, 2005 at 05:20:07PM +0200, Hans-Jürgen Schönig wrote:
Maybe not, but if it happens again then please post the stack trace
so somebody can take a look. Even if it isn't a PostgreSQL problem,
it's worth finding out the cause so you can prevent it in the future.

--
Michael Fuhr
http://www.fuhr.org/~mfuhr/

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq