Thread: catastrophic error

catastrophic error

From
"Joel Fradkin"
Date:

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
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.

 


 

 

Re: catastrophic error

From
"Matthew T. O'Connor"
Date:
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.
>
>
>
>
>
>
>
>

Re: catastrophic error

From
Bricklen Anderson
Date:
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.
_______________________________

Re: catastrophic error

From
"Joel Fradkin"
Date:
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.
_______________________________


Re: [ODBC] catastrophic error

From
Marko Ristola
Date:
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
>
>
>


Re: [ODBC] catastrophic error

From
"Joel Fradkin"
Date:
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
>
>
>