From: | Dr NoName <spamacct11(at)yahoo(dot)com> |
---|---|
To: | Richard Sydney-Smith <richard(at)ibisau(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: transaction timeout |
Date: | 2005-07-26 17:51:16 |
Message-ID: | 20050726175116.11807.qmail@web31503.mail.mud.yahoo.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
> If you have second database in the cluster is it
> still operational when
> the main database locks up?
we don't have a DB cluster. It would be pretty useless
since postgresql doesn't support distributed
transactions.
> Also it seems that some diagnostics are needed in
> the client app to log
> the crash event so you can determine which SQL
> commands are causing the
> lock.
I'll try to get that next time it happens. But
regardless of sql commands are running, I know what
the root cause is: a client hangs while in
transaction.
> Despite many years of writing buggy code I have not
> yet locked a whole
> DB in the fashion described. I can not see how a
> simple select / insert
> / update command sequence can achieve it unless
> there is a particular
> relation between the tables involved.
As I have already said, I suspect this might be caused
by a combination of an open transaction and a weekly
VACUUM FULL. Does that sound right?
> If the tables are related / linked via rules /
> triggers/ keys then
> perhaps add a test table that bears no relation to
> the others and see if
> it is locked when the others appear to have this
> problem you are describing.
>
> Perhaps a simple test : When the DB error occurs can
> you use PGAdmin to
> read an independent table, or read from another
> database.
thanks, I'll try that.
Eugene
____________________________________________________
Start your day with Yahoo! - make it your home page
http://www.yahoo.com/r/hs
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2005-07-26 17:56:51 | Re: Trigger disactivation and SELECT WAITING |
Previous Message | Magnus Hagander | 2005-07-26 17:41:13 | Re: transaction timeout |