From: | Terrence Brannon <metaperl(at)mac(dot)com> |
---|---|
To: | andrew_perrin(at)unc(dot)edu |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Any way to figure out why a session stopped? |
Date: | 2002-01-13 17:27:19 |
Message-ID: | CBD91BB4-084A-11D6-9EDB-003065C2A10C@mac.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Thursday, January 3, 2002, at 07:13 PM, Andrew Perrin wrote:
> Greetings-
>
> I was running a large job, started on Wednesday evening. The job, which
> used a perl script and DBI to do some manipulation and pattern
> extraction
> from full-text documents in a PostgreSQL database (version 7.1.3,
> running
> on debian linux), stopped about 1/3 of the way through its task.
>
> Unfortunately, I don't still have the window open from which I ran the
> script. Is there any way to figure out why it stopped,
perldoc DBI will tell you:
<quote>
"trace"
DBI->trace($trace_level)
DBI->trace($trace_level, $trace_filename)
DBI trace information can be enabled for all handles
using the "trace" DBI class method. To enable trace
information for a specific handle, use the similar
"$h-">"trace" method described elsewhere.
Trace levels are as follows:
0 - Trace disabled.
1 - Trace DBI method calls returning with results or
errors.
2 - Trace method entry with parameters and returning
with results.
3 - As above, adding some high-level information
from the driver
and some internal information from the DBI.
4 - As above, adding more detailed information from
the driver.
Also includes DBI mutex information when using
threaded Perl.
5 and above - As above but with more and more
obscure information.
Trace level 1 is best for a simple overview of what's
happening.
</quote>
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2002-01-13 17:45:55 | Re: compiling pg_check |
Previous Message | Tom Lane | 2002-01-13 17:09:23 | Re: mysql-pgsql comparison |