I wrote:
> Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes:
>> Configuration affects what can be tested in installcheck, that's quite
>> natural. I would be happy with simply adding an alternative expected
>> output file for min_prepared_xacts=0 case. Like we've done for xml test
>> cases, for example, though that's a compile-time option.
> Hmm, that's true; the xml case is a relevant precedent. This would be
> a pretty low-effort way of addressing the problem. Another nice thing
> about it is that we'd stop having a default max_prepared_transactions
> value that's completely useless (5 is guaranteed to be either too much
> or not enough...)
The more I think about this the more I like it. The current default of
5 never had any justification beyond allowing the regression tests to
run --- it's almost certainly not enough for production usage of the
feature, but it exposes you to all of the downsides of accidental use.
If we change it to zero, we could alter the Notes for PREPARE
TRANSACTION to urge more strongly that the feature not be enabled
without having set up appropriate external infrastructure.
Warning about very old prepared transactions is something that we
could think about doing as well; it doesn't have to be either-or.
I think the need for it would decrease quite a bit if they weren't
enabled by default, though.
Comments? Anyone seriously opposed to making the default be zero?
regards, tom lane