Josh Berkus wrote:
> It occurs to me that another way of diagnosis would simply be a way to
> cause the autovac daemon to spit out output we could camp on, *without*
> requiring the huge volumes of output also required for DEBUG3. This
> brings us back to the logging idea again.
>
Right. I don't know how much you looked at the little patch I threw out
there yet, but I think it's a reasonable 90% solution to the problem of
"how do I distinguish between a locking block and other reasons for AV
not running?" without generating a huge amount of log data. Since
there's no real overhead or code complexity added by it, it's a
relatively easy thing to throw in the codebase without annoying anyone.
> I really don't think that argument applies to either patch;
> last_autovac_attempt *or* the last_stats_reset time, since neither event
> is expected to occur frequently. If you have last_autovac_attempt (for
> example) being updated frequently, you clearly had a db problem bigger
> than the size of the stats table.
>
It just returns to the usual "why make everyone pay overhead for
something that only happens to a small percentage of users?"
argument.[1] I personally have all sorts of additional data I'd like to
instrument in myriad obtrusive spots of code. All I'm saying is that
this one in particular I don't quite feel strongly enough about to make
it the spot I try to establish that foothold at. If a stats tracking
patch for this appeared that seemed reasonably well written (i.e. it
tries to keep the added value NULL whenever it's not relevant), I'd be
in favor of it going in. I'm just not so excited about the idea that
I'm going to write it. I'm lukewarm to per-table last_stats_reset time
just because there's so few places I'd actually use it in practice,
relative to the guaranteed overhead it adds.
[1] Silly aside: I was thinking today that I should draw a chart of all
the common objections to code that show up here, looking like those maps
you see when walking into a mall. Then we can give a copy to new
submitters with a big "you are here" X marking where they have
inadvertently wandered onto.
--
Greg Smith 2ndQuadrant US greg@2ndQuadrant.com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.us
"PostgreSQL 9.0 High Performance": http://www.2ndQuadrant.com/books