On Wednesday 22 April 2009 15:49:32 Tom Lane wrote: > I wrote: > > Heikki Linnakangas <heikki.linnakan...@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? >
I see this has already been committed, and I am not seriously opposed to changing it, but I wanted to chime in on a point no one seemed to raise. I used to recommend people set this to 0 pretty regularly, since most web shops don't even know what prepared transactions are, let alone use them. I got less agressive about this after a few people reported to me that they had run out of lock slots on thier systems. Now, you'd think that ~300 lock slots wouldn't make that much difference, but it did make me a little nervous; so I thought I'd mention it. -- Robert Treat Conjecture: http://www.xzilla.net Consulting: http://www.omniti.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers