| From: | Andres Freund <andres(at)2ndquadrant(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Josh Berkus <josh(at)agliodbs(dot)com>, Kevin Grittner <kgrittn(at)ymail(dot)com>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Vik Fearing <vik(dot)fearing(at)dalibo(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Andrew Dunstan <andrew(at)dunslane(dot)net> |
| Subject: | Re: idle_in_transaction_timeout |
| Date: | 2014-06-24 17:29:51 |
| Message-ID: | 20140624172951.GE24114@awork2.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 2014-06-24 10:17:49 -0700, Tom Lane wrote:
> BTW, has anyone thought about the interaction of this feature with
> prepared transactions? I wonder whether there shouldn't be a similar but
> separately-settable maximum time for a transaction to stay in the prepared
> state. If we could set a nonzero default on that, perhaps on the order of
> a few minutes, we could solve the ancient bugaboo that "prepared
> transactions are too dangerous to enable by default".
I'd very much like that feature, but I'm not sure how to implement
it. Which process would do that check? We currently only allow rollbacks
from the corresponding database...
The best idea I have is to do it via autovacuum.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Fujii Masao | 2014-06-24 17:35:50 | Re: pgaudit - an auditing extension for PostgreSQL |
| Previous Message | Andres Freund | 2014-06-24 17:27:43 | Re: Atomics hardware support table & supported architectures |