From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Bruce Momjian <bruce(at)momjian(dot)us> |
Cc: | "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, Russell Smith <mr-russ(at)pws(dot)com(dot)au>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Feature thought: idle in transaction timeout |
Date: | 2007-04-03 02:39:26 |
Message-ID: | 14216.1175567966@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Bruce Momjian <bruce(at)momjian(dot)us> 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 message without getting out-of-sync with the client,
which will likely take the error as the response to its next command
and thenceforth be very confused. What we'll probably have to do to
make this work is abort the transaction upon timeout (so that VACUUM et
al can get on with things) but not report the error to the client until
its next command. And if said next command happens to be ROLLBACK then
there's nothing to complain of at all.
Doable, probably, but seems a bit messy.
regards, tom lane
PS: the only case where we currently send an unsolicited ERROR is during
SIGTERM or SIGQUIT shutdown; where it doesn't matter if we're out of
sync because we're killing the session anyway.
From | Date | Subject | |
---|---|---|---|
Next Message | Hideyuki Kawashima | 2007-04-03 03:49:27 | Re: Acclerating INSERT/UPDATE using UPS |
Previous Message | Joshua D. Drake | 2007-04-03 02:36:18 | Re: Feature thought: idle in transaction timeout |