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 g...@2ndquadrant.com Baltimore, MD PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.us "PostgreSQL 9.0 High Performance": http://www.2ndQuadrant.com/books -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
