On Sun, Feb 15, 2015 at 11:36:50AM -0500, Tom Lane wrote: > I wonder if we couldn't achieve largely the same positive effects through > adding a simple transaction-level timeout option. That would be far > easier for users to understand and manage, it would be trivial to allow > specific high-value transactions to run with a laxer setting, it does not > create any implementation-detail-dependent behavior that we'd be having to > explain to users forevermore, and (not incidentally) it would be a lot > simpler and more trustworthy to implement. There's no well-defined > correlation between your setting and the net effect on database bloat, > but that's true with the "snapshot too old" approach as well.
While we have prided ourselves on not generating query cancel messages due to snapshot-too-old, there is the downside of bloat. I understand the need to allow users to make the trade-off between bloat and query cancellation. It seems we already have a mechanism in place that allows tuning of query cancel on standbys vs. preventing standby queries from seeing old data, specifically max_standby_streaming_delay/max_standby_archive_delay. We obsessed about how users were going to react to these odd variables, but there has been little negative feedback. -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
