Обсуждение: Database handle destroyed without explicit disconnect
Tom Lane kindly steered me in the right direction to solve a physical disk drive problem after I posted my "'could not
readblock' error messages" message to this list on Jan. 8. After correcting the hardware problem, the script that
wasn'tworking on Jan. 8 is now working. Thank you, Mr. Lane, for your guidance.
A new problem has now bubbled to the surface. Another perl script that worked flawlessly for many years extracting
datafrom a PostgreSQL database and writing content to text files stopped working on Dec. 21. When I run the script
manuallytoday, I receive this error message:
DBD::Pg::db selectall_arrayref failed: server closed the connection unexpectedly at {script} line 692.
DBD::Pg::db selectall_arrayref failed: server closed the connection unexpectedly at {script} line 692.
Database handle destroyed without explicit disconnect.
Line 692 of the script says:
my $ary_get = $dbhandle->selectall_arrayref($get);
The FreeBSD box hosting PostgreSQL shows this message in its /var/log/messages file everytime the script runs:
Jan 27 14:07:11 midas /kernel: pid 36906 (postgres), uid 70: exited on signal 11 (core dumped)
peter@vfemail.net writes:
> The FreeBSD box hosting PostgreSQL shows this message in its /var/log/messages file everytime the script runs:
> Jan 27 14:07:11 midas /kernel: pid 36906 (postgres), uid 70: exited on signal 11 (core dumped)
Can you get a stack trace out of one of those core dumps? Or at least
determine what query it was trying to execute? What PG version is that
anyway?
regards, tom lane
Maybe. How would I do that? I'm running whatever version of PostgreSQL was current in mid-2004. I have the feeling that I'm most novice novice subscribed to this mailing list. ------- At 05:41 PM 1/27/2010, Tom Lane wrote: >peter@vfemail.net writes: >> The FreeBSD box hosting PostgreSQL shows this message in its /var/log/messages file everytime the script runs: > >> Jan 27 14:07:11 midas /kernel: pid 36906 (postgres), uid 70: exited on signal 11 (core dumped) > >Can you get a stack trace out of one of those core dumps? Or at least >determine what query it was trying to execute? What PG version is that >anyway? > > regards, tom lane
peter@vfemail.net writes: > Maybe. How would I do that? I'm running whatever version of PostgreSQL was current in mid-2004. 2004 was a very long time ago :-(. A quick look at the release history suggests that you could not be running anything newer than about 7.4.2, and it could easily be a 7.3.x release or something even older instead. You really ought to update the server version before expending any additional thought on this, since the odds are reasonably good that that crash is something we fixed long since. Do "select version();" to see exactly what version you have got, and then see about updating to the latest minor release in that major release series. Such an update should be relatively painless (no dump and reload) though it'd still be smart to peruse the release notes to see if there were any small behavioral changes that might affect your applications: http://developer.postgresql.org/pgdocs/postgres/release.html If you still see the crash on the latest minor version, it'd be worth probing deeper. regards, tom lane
It took me a week to figure out how to figure out how and where to enter that "select version();" command. I've figured out that I am running PostgreSQL 7.4.3 on i386-portbld-freebsd4.10, compiled by GCC 2.95.4. I'm guessing, after looking at <http://www.postgresql.org/>http://www.postgresql.org/ that I should upgrade to Version 7.4.27,correct? This upgrade won't confuse old shell, PHP and Perl scripts or otherwise confuse FreeBSD, correct? Can you point me to novice-friendly step-by-step instructions? -------- At 06:50 PM 1/27/2010, Tom Lane wrote: >peter@vfemail.net writes: >> Maybe. How would I do that? I'm running whatever version of PostgreSQL was current in mid-2004. > >2004 was a very long time ago :-(. A quick look at the release history >suggests that you could not be running anything newer than about 7.4.2, >and it could easily be a 7.3.x release or something even older instead. >You really ought to update the server version before expending any >additional thought on this, since the odds are reasonably good that that >crash is something we fixed long since. > >Do "select version();" to see exactly what version you have got, and >then see about updating to the latest minor release in that major >release series. Such an update should be relatively painless (no dump >and reload) though it'd still be smart to peruse the release notes to >see if there were any small behavioral changes that might affect your >applications: >http://developer.postgresql.org/pgdocs/postgres/release.html > >If you still see the crash on the latest minor version, it'd be worth >probing deeper. > > regards, tom lane