Ühel kenal päeval, E, 2007-04-02 kell 19:36, kirjutas Joshua D. Drake:
> Tom Lane wrote:
> > "Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> >> Bruce Momjian wrote:
> >>> Added to TODO:
> >>> * Add idle_timeout GUC so locks are not held for log periods of time
> >
> >> That should actually be tran
TODO updated:
* Add idle_in_transaction_timeout GUC so locks are not held for long
periods of time
---
Joshua D. Drake wrote:
> Tom Lane wrote:
> > "Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> >> Bruce Momjian wrote:
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Added to TODO:
> * Add idle_timeout GUC so locks are not held for log periods of time
BTW, before I forget it: there's a non-obvious consideration here, which
is not breaking the query protocol. I suspect that we cannot send an
unsolicited ERROR m
Tom Lane wrote:
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
Bruce Momjian wrote:
Added to TODO:
* Add idle_timeout GUC so locks are not held for log periods of time
That should actually be transaction_idle_timeout. It is o.k. for us to
be IDLE... it is not o.k. for us to be IDLE in Transac
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> Bruce Momjian wrote:
>> Added to TODO:
>> * Add idle_timeout GUC so locks are not held for log periods of time
> That should actually be transaction_idle_timeout. It is o.k. for us to
> be IDLE... it is not o.k. for us to be IDLE in Transaction
Or
Fixed.
---
Andrew Dunstan wrote:
> Bruce Momjian wrote:
> > Added to TODO:
> >
> > * Add idle_timeout GUC so locks are not held for log periods of time
> >
> >
> >
>
> ITYM long periods.
>
>
> cheers
>
>
> andrew
fixed.
---
Joshua D. Drake wrote:
> Bruce Momjian wrote:
> > Added to TODO:
> >
> > * Add idle_timeout GUC so locks are not held for log periods of time
> >
>
> That should actually be transaction_idle_timeout. It is
Bruce Momjian wrote:
Added to TODO:
* Add idle_timeout GUC so locks are not held for log periods of time
ITYM long periods.
cheers
andrew
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://
Bruce Momjian wrote:
Added to TODO:
* Add idle_timeout GUC so locks are not held for log periods of time
That should actually be transaction_idle_timeout. It is o.k. for us to
be IDLE... it is not o.k. for us to be IDLE in Transaction
Joshua D. Drake
-
Added to TODO:
* Add idle_timeout GUC so locks are not held for log periods of time
---
Tom Lane wrote:
> "Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> > Russell Smith wrote:
> >> I agree with this, it reduces th
Tom Lane wrote:
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
Russell Smith wrote:
I agree with this, it reduces the long running transaction problem a
little where the user forgot to commit/rollback their session. I may be
worth having a transaction_timeout as well, and setting it to link a
Tom Lane wrote:
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
Russell Smith wrote:
I agree with this, it reduces the long running transaction problem a
little where the user forgot to commit/rollback their session. I may be
worth having a transaction_timeout as well, and setting it to link a
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> Russell Smith wrote:
>> I agree with this, it reduces the long running transaction problem a
>> little where the user forgot to commit/rollback their session. I may be
>> worth having a transaction_timeout as well, and setting it to link a few
>>
Russell Smith wrote:
Joshua D. Drake wrote:
Hello,
I ran into an interesting problem with a customer today. They are
running Jabber XCP (not the one we use). Unfortunately, the product
has a bug that causes it to leave connections persistent in a
transaction state. This is what it does:
BE
Joshua D. Drake wrote:
Hello,
I ran into an interesting problem with a customer today. They are
running Jabber XCP (not the one we use). Unfortunately, the product
has a bug that causes it to leave connections persistent in a
transaction state. This is what it does:
BEGIN; SELECT 1;
Basica
Hello,
I ran into an interesting problem with a customer today. They are
running Jabber XCP (not the one we use). Unfortunately, the product has
a bug that causes it to leave connections persistent in a transaction
state. This is what it does:
BEGIN; SELECT 1;
Basically it is verifying that
16 matches
Mail list logo