Thread: catastrophic error

If you could connect to the database server from the web server and get
data with PGAdmin then it doesn't' sound like a database or database
server problem.  How is your web app connecting to the database?  ODBC?
That might be a bit of an issue.  PgAdmin doesn't use ODBC, it uses
libpq directly.

Joel Fradkin wrote:

> Hi,
>
>
>
> I have been live for 4 days (vacuums run each night and backups done
> each night).
>
> Today around 2:30 PM  EST my web app returned a catastrophic error.
>
> Both web servers appeared to have the issue.
>
> I could go on them and get data via pgadmin.
>
> I could log on the server (IIS servers are win2k and pg is Redhat AS4
> running 8.0.2) and see it was not using much memory or cpu.
>
> Neither the web or database servers seemed stressed?
>
> Any ideas what I should look at?
>
> I re-booted the IIS servers and it did not fix the issue.
>
> I rebooted the database server and the web servers are back to connecting.
>
>
>
> Being new to postgres I am not sure what to look at for the cause and
> hopefully permanent fix to this.
>
>
>
> Thanks in advance to any ideas (I did search the archive, but only saw
> a mention of pre 8 versions and oid numbering wraparound).
>
>
>
> Joel Fradkin
>
>
>
> Wazagua, Inc.
> 2520 Trailmate Dr
> Sarasota, Florida 34243
> Tel.  941-753-7111 ext 305
>
>
>
> jfradkin@wazagua.com <mailto:jfradkin@wazagua.com>
> www.wazagua.com <http://www.wazagua.com>
> Powered by Wazagua
> Providing you with the latest Web-based technology & advanced tools.
> © 2004. WAZAGUA, Inc. All rights reserved. WAZAGUA, Inc
>  This email message is for the use of the intended recipient(s) and
> may contain confidential and privileged information.  Any unauthorized
> review, use, disclosure or distribution is prohibited.  If you are not
> the intended recipient, please contact the sender by reply email and
> delete and destroy all copies of the original message, including
> attachments.
>
>
>
>
>
>
>
>

Joel Fradkin wrote:
> Hi,
>
>
>
> I have been live for 4 days (vacuums run each night and backups done
> each night).
>
> Today around 2:30 PM  EST my web app returned a catastrophic error.
>
> Both web servers appeared to have the issue.
>
> I could go on them and get data via pgadmin.
>
> I could log on the server (IIS servers are win2k and pg is Redhat AS4
> running 8.0.2) and see it was not using much memory or cpu.
>
> Neither the web or database servers seemed stressed?
>
> Any ideas what I should look at?
>
> I re-booted the IIS servers and it did not fix the issue.
>
> I rebooted the database server and the web servers are back to connecting.
>
>
>
> Being new to postgres I am not sure what to look at for the cause and
> hopefully permanent fix to this.
>
>
>
> Thanks in advance to any ideas (I did search the archive, but only saw a
> mention of pre 8 versions and oid numbering wraparound).
>
>
>
> Joel Fradkin

Any messages in syslog on db server? Any web error logs that you can check?

--
_______________________________

This e-mail may be privileged and/or confidential, and the sender does
not waive any related rights and obligations. Any distribution, use or
copying of this e-mail or the information it contains by other than an
intended recipient is unauthorized. If you received this e-mail in
error, please advise me (by return e-mail or otherwise) immediately.
_______________________________

The catastrophic error was the actual text sent from the IIS component
error.

SO I am not 100% sure what it means, I believe it is just mirroring back
text from the dbserver when trying to connect and failing.

I am guessing it is odbc and I am currently using the 7.4 version, but am
looking for the best way to move from SQL_ASCHII to UNICODE (maybe a backup
and restore using some kind of params? I hope?

If not I guess I could alter my original program that read MSSQL to read
from postgres and write it back to a Unicode database and see if the odbc
drivers are ok (it originally blew up and that's how I ended up using
SQL_ASCHII).

Joel Fradkin

What does a catastrophic error consist of? Do you mean your IIS servers
could no longer connect to the db, and yet you _could_ connect to the db via
pgadmin? Yes the web interface gave that as the conection error string (my
error routine just prints that to the screen)
I would have thought that rebooting the IIS would have solved any
connectivity issues (assuming that that is the error that you are getting).
I've never used IIS, so I can't even guess about that. ODBC is a
possibility, I suppose, and it certainly wouldn't hurt to try again on the
ODBC list.


Cheers,

Bricklen

--
_______________________________

This e-mail may be privileged and/or confidential, and the sender does
not waive any related rights and obligations. Any distribution, use or
copying of this e-mail or the information it contains by other than an
intended recipient is unauthorized. If you received this e-mail in
error, please advise me (by return e-mail or otherwise) immediately.
_______________________________

About ASCII to Unicode conversion (if you have only Latin1 characters in
the database):

Here is a receipt, how you can do a charset conversion from SQL_ASCII into
UNICODE on the Linux side:
(check these from manual pages first!):

1. Stop PostgreSQL and make a good backup!
"su - postgres" ; "pg_dumpall -D > everything-latin1.dump"
"file everything-latin1.dump" might tell you the charset.
Watch out for \345 style octal numbers, because iconv character
converter won't see them.
PostgreSQL protects non-ascii characters that way at least in ASCII backups.

(The -D above makes the restore phase slow. I use it if I switch a
PostgreSQL version,
because the rows are standard SQL sentences. Very portable.
The slowness can be resolved at least by filtering the
file with AWK and combining many inserts into a single transaction
(BEGIN,many inserts, COMMIT). )

cat everything-latin1.dump | iconv -f LATIN1 -t  UTF-8 >
everything-utf8.dump
stop PostgreSQL.
remove the old database
Check PostgreSQL configuration files!
su - postgres
initdb with UTF-8.
su - postgres ; psql -f everything-utf8.dump template1

Please check the above phases, but that is approximately, how it goes.
Additional documentation: man pg_dumpall, man initdb, man createdb, man
psql, man iconv

Database speed:
speed loader format is fastest on restore (pg_dumpall without -D).
Inserts within reasonable sized transactions are lots
of faster than inserts in autocommit mode (pg_dumpall with -D).


Good night.

Marko Ristola

Joel Fradkin wrote:

>The catastrophic error was the actual text sent from the IIS component
>error.
>
>SO I am not 100% sure what it means, I believe it is just mirroring back
>text from the dbserver when trying to connect and failing.
>
>I am guessing it is odbc and I am currently using the 7.4 version, but am
>looking for the best way to move from SQL_ASCHII to UNICODE (maybe a backup
>and restore using some kind of params? I hope?
>
>If not I guess I could alter my original program that read MSSQL to read
>from postgres and write it back to a Unicode database and see if the odbc
>drivers are ok (it originally blew up and that's how I ended up using
>SQL_ASCHII).
>
>Joel Fradkin
>
>What does a catastrophic error consist of? Do you mean your IIS servers
>could no longer connect to the db, and yet you _could_ connect to the db via
>pgadmin? Yes the web interface gave that as the conection error string (my
>error routine just prints that to the screen)
>I would have thought that rebooting the IIS would have solved any
>connectivity issues (assuming that that is the error that you are getting).
>I've never used IIS, so I can't even guess about that. ODBC is a
>possibility, I suppose, and it certainly wouldn't hurt to try again on the
>ODBC list.
>
>
>Cheers,
>
>Bricklen
>
>
>

Thank you much I will give it a try and see how it goes appreciate all the
info.

About ASCII to Unicode conversion (if you have only Latin1 characters in
the database):

Here is a receipt, how you can do a charset conversion from SQL_ASCII into
UNICODE on the Linux side:
(check these from manual pages first!):

1. Stop PostgreSQL and make a good backup!
"su - postgres" ; "pg_dumpall -D > everything-latin1.dump"
"file everything-latin1.dump" might tell you the charset.
Watch out for \345 style octal numbers, because iconv character
converter won't see them.
PostgreSQL protects non-ascii characters that way at least in ASCII backups.

(The -D above makes the restore phase slow. I use it if I switch a
PostgreSQL version,
because the rows are standard SQL sentences. Very portable.
The slowness can be resolved at least by filtering the
file with AWK and combining many inserts into a single transaction
(BEGIN,many inserts, COMMIT). )

cat everything-latin1.dump | iconv -f LATIN1 -t  UTF-8 >
everything-utf8.dump
stop PostgreSQL.
remove the old database
Check PostgreSQL configuration files!
su - postgres
initdb with UTF-8.
su - postgres ; psql -f everything-utf8.dump template1

Please check the above phases, but that is approximately, how it goes.
Additional documentation: man pg_dumpall, man initdb, man createdb, man
psql, man iconv

Database speed:
speed loader format is fastest on restore (pg_dumpall without -D).
Inserts within reasonable sized transactions are lots
of faster than inserts in autocommit mode (pg_dumpall with -D).


Good night.

Marko Ristola

Joel Fradkin wrote:

>The catastrophic error was the actual text sent from the IIS component
>error.
>
>SO I am not 100% sure what it means, I believe it is just mirroring back
>text from the dbserver when trying to connect and failing.
>
>I am guessing it is odbc and I am currently using the 7.4 version, but am
>looking for the best way to move from SQL_ASCHII to UNICODE (maybe a backup
>and restore using some kind of params? I hope?
>
>If not I guess I could alter my original program that read MSSQL to read
>from postgres and write it back to a Unicode database and see if the odbc
>drivers are ok (it originally blew up and that's how I ended up using
>SQL_ASCHII).
>
>Joel Fradkin
>
>What does a catastrophic error consist of? Do you mean your IIS servers
>could no longer connect to the db, and yet you _could_ connect to the db
via
>pgadmin? Yes the web interface gave that as the conection error string (my
>error routine just prints that to the screen)
>I would have thought that rebooting the IIS would have solved any
>connectivity issues (assuming that that is the error that you are getting).
>I've never used IIS, so I can't even guess about that. ODBC is a
>possibility, I suppose, and it certainly wouldn't hurt to try again on the
>ODBC list.
>
>
>Cheers,
>
>Bricklen
>
>
>