Brian Cox writes:
> Actually, they're all deadlocked. The question is why?
Probably because the DROP is trying to acquire exclusive lock on its
target table, and some other transaction already has a read or write
lock on that table, and everything else is queuing up behind the DROP.
It's not a t
Ross J. Reedstrom escribió:
Excellent. I'll take a look at this and report back here.
Ross
On Mon, Feb 23, 2009 at 04:17:00PM -0500, Tom Lane wrote:
"Ross J. Reedstrom" writes:
Summary: C client and large-object API python both send bits in
reasonable time, but I suspect there's still room
Linos writes:
> Hello, i have been having a problem like this in debian machines and i have
> discovered that (almost in my case), the problem only arises when i am using
> "ssl = true" in postgresql.conf although i am using clear tcp connections to
> localhost to perform my query, if i disable
Tom Lane escribió:
Linos writes:
Hello, i have been having a problem like this in debian machines and i have
discovered that (almost in my case), the problem only arises when i am using
"ssl = true" in postgresql.conf although i am using clear tcp connections to
localhost to perform my query,
Linos writes:
> Tom Lane escribió:
>> Does that number include connection startup overhead? (If it doesn't,
>> it'd be pretty strange.)
> This difference it is from the runtime of the query, i get this with \timing
> parameter in psql,
That's just weird --- ssl off should be ssl off no matter
Tom Lane escribió:
Linos writes:
Tom Lane escribió:
Does that number include connection startup overhead? (If it doesn't,
it'd be pretty strange.)
This difference it is from the runtime of the query, i get this with \timing
parameter in psql,
That's just weird --- ssl off should be ssl o
Linos writes:
> Tom Lane escribió:
>> That's just weird --- ssl off should be ssl off no matter which knob you
>> use to turn it off. Are you sure it's really off in the slow connections?
> Maybe i am missing something, i use the same command to connect to it
> from localhost "psql -d database -
Tom Lane wrote:
> Linos writes:
>> Tom Lane escribió:
>>> That's just weird --- ssl off should be ssl off no matter which knob you
>>> use to turn it off. Are you sure it's really off in the slow connections?
>
>> Maybe i am missing something, i use the same command to connect to it
>> from loca
Magnus Hagander escribió:
Tom Lane wrote:
Linos writes:
Tom Lane escribió:
That's just weird --- ssl off should be ssl off no matter which knob you
use to turn it off. Are you sure it's really off in the slow connections?
Maybe i am missing something, i use the same command to connect to it
>Probably because the DROP is trying to acquire exclusive lock on its
>target table, and some other transaction already has a read or write
>lock on that table, and everything else is queuing up behind the DROP.
>It's not a true deadlock that is visible to the database, or else
>Postgres would ha
"Cox, Brian" writes:
>> Probably because the DROP is trying to acquire exclusive lock on its
>> target table, and some other transaction already has a read or write
>> lock on that table, and everything else is queuing up behind the DROP.
>> It's not a true deadlock that is visible to the databas
11 matches
Mail list logo
