Tom Lane <tgl@sss.pgh.pa.us> wrote:
> But Kevin's question seemed to be based on the assumption that
> runtime cost was the only negative. It wouldn't be terribly hard
> to make a variant of cassert that skips two or three of the most
> expensive things (particularly memory context checking and
> CLOBBER_FREED_MEMORY), and from a cost perspective that would be
> totally reasonable to run in production. We haven't done it
> because of the stability issue.
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....
-Kevin
