From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Rich Garabedian" <richg(at)mav-mail(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Debugging guidance |
Date: | 2002-10-25 14:21:38 |
Message-ID: | 22793.1035555698@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
"Rich Garabedian" <richg(at)mav-mail(dot)com> writes:
> I've inherited a fairly complex database that makes heavy use of plpgsql.
> Recently, this database has been crashing at random times when it tries to
> execute a specific plpgsql function.
Ugh.
> I'm very new to postgreSQL, and I'm not much of database guru either. Can
> anyone suggest further debugging avenues?
1. Update to PG 7.2.3. We don't put out dot-releases without good
reason. (It's entirely possible that your problem is just the
plpgsql_dstring_append bug fixed in 7.2.2.) If you still see the
problem, then:
2. Build the new installation with --enable-debug, and maybe also
--enable-cassert. (--enable-debug is harmless to leave on in
production, except for wasting a couple of megabytes of disk space.
--enable-cassert will slow things down a trifle, so you'd only want
to use it when chasing a problem, IMHO.) I am not sure whether any
RPMs come built this way; you may need to build from source.
(Anyone know if an SRPM can easily be built with --enable-debug added?)
3. Make sure the postmaster is started with "ulimit -c unlimited";
this is not the default on a lot of Linux distros. This way, you'll
get a core-dump file in the database subdirectory when a backend
crash occurs.
4. Use gdb to get a stack backtrace from the core file, and send it
to pgsql-hackers for more help.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Douglas Blood | 2002-10-25 15:10:32 | Inserting and Updating |
Previous Message | Andrew Sullivan | 2002-10-25 14:18:27 | Re: postgresql 7.2.1 and smp ? |