|From:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>|
|To:||Josh Berkus <josh(at)agliodbs(dot)com>|
|Cc:||Andres Freund <andres(at)2ndquadrant(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>|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
Josh Berkus <josh(at)agliodbs(dot)com> writes:
> On 06/23/2014 03:52 PM, Andres Freund wrote:
>> True. Which makes me wonder whether we shouldn't default this to
>> something non-zero -- even if it is 5 or 10 days.
> I'd go for even shorter: 48 hours. I'd suggest 24 hours, but that would
> trip up some users who just need really long pg_dumps.
FWIW, I do not think we should have a nonzero default for this.
We could not safely set it to any value that would be small enough
to be really useful in the field.
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".
regards, tom lane
|Next Message||Tom Lane||2014-06-24 17:22:08||Re: Atomics hardware support table & supported architectures|
|Previous Message||Andres Freund||2014-06-24 17:09:08||Re: Atomics hardware support table & supported architectures|