From: | "Dan Armbrust" <daniel(dot)armbrust(dot)list(at)gmail(dot)com> |
---|---|
To: | "pgsql general" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Deadlock situation? |
Date: | 2008-04-30 16:17:23 |
Message-ID: | 82f04dc40804300917o4882e0cbh358a197d57523f4e@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
> I wonder whether you saw some variant of the deadlock reported in bug
> #3883 --- see discussion here:
> http://archives.postgresql.org/pgsql-hackers/2008-01/msg00873.php
> The only known way of getting into that problem is fixed in 8.3,
> but a potential for silent deadlock is definitely still there.
> I don't however have any idea how such a deadlock could occur without
> at least some processes showing as 'waiting' in pg_stat_activity.
>
> Do you have any idea what the transactions that were blocked at
> COMMIT had been doing?
Should have just been selects and updates, and perhaps some inserts
and deletes - nothing to out of the ordinary or complex.
If I can get this to happen consistently, I'll set up a logger to
capture all of the SQL statements leading up to the freeze.
>
> Are there any foreign key constraints leading *to* this table?
Nope.
Unfortunately, I had been running for a couple of weeks steady before
I got the error - so reproducing it may not be quick. But I'm going
to set up a couple of parallel tests on more systems, and see if I can
happen into it again sooner.
Oh, and I don't think though should have anything to do with it, but I
did discover that fsync was turned off on this postgres instance.
Someone else didn't clean up after a different test, and I forgot to
change it back.
Thanks,
Dan
From | Date | Subject | |
---|---|---|---|
Next Message | Andy Anderson | 2008-04-30 16:51:45 | Re: Quoting " |
Previous Message | Alvaro Herrera | 2008-04-30 16:13:15 | Re: Why is postgres autovacuuming a table that is never updated? |