Kevin Grittner wrote:
> Fair enough. I was thinking of them both as debugging features,
> which had various ideas roiling around in my head. Having run
> hundreds of databases 24/7 for years without ever needing this
> information, but paying the cost for it one way or another every
> day, my perspective is that it would be A Good Thing if it could
> just be turned on when needed. If you have recurring bug that can
> be arranged, but in those cases you have other options; so I'm
> assuming you want this kept because it is primarily of forensic
> value after a non-repeatable bug has munged something?
>
> Another thought bouncing around was that these breadcrumbs are
> expensive; I was trying to think of some other way to capture the
> information which would be cheaper, but I haven't thought of
> anything, and I'm far from certain that cheaper breadcrumbs to
> answer the need can be developed. The best thought I've had so far
> is that if someone kept WAL files long enough the evidence might be
> in there somewhere....
The idea that thousands of Postgres installations are slower just so we
can occasionally debug xmin/xmax issues seems way off balance to me.
If people want debugging, let them modify the freeze age settings; the
defaults should not favor debugging when there is a measurable cost
involved. How many times in the past five years have we even needed
such debugging information, and also are cases where we could not have
told the user to change freeze settings to get us that info?
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ None of us is going to be here forever. +
