Tom Lane kindly steered me in the right direction to solve a physical disk drive problem after I posted my "'could not read block' error messages" message to this list on Jan. 8. After correcting the hardware problem, the script that wasn't working 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 data from a PostgreSQL database and writing content to text files stopped working on Dec. 21. When I run the script manually today, 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)

Search Discussions

  • Tom Lane at Jan 27, 2010 at 10:42 pm

    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 at Jan 27, 2010 at 11:25 pm
    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
  • Tom Lane at Jan 27, 2010 at 11:51 pm

    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
  • Peter at Feb 6, 2010 at 2:25 pm
    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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppgsql-novice @
categoriespostgresql
postedJan 27, '10 at 8:08p
activeFeb 6, '10 at 2:25p
posts5
users2
websitepostgresql.org
irc#postgresql

2 users in discussion

Peter: 3 posts Tom Lane: 2 posts

People

Translate

site design / logo © 2022 Grokbase