On Sun, Oct 4, 2015 at 1:01 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Ah, right, sorry. I meant to make its result match what gc_texts would > get, by not falsely counting entries with dropped texts. That's not > what you have in your patch but it seems like an easy enough fix.
I'm trying to make mean_query_len representative of *useful* entry query length. I guess I don't have that within gc_texts in my patch, but I do have it within entry_dealloc (up to and including considering dropped texts), which FWIW is far more important. >> I'd be quite happy if you did everything listed, and also left the >> extra discrimination against sticky entries within entry_dealloc in -- >> consider what happens when a huge malloc() ends up swapping with an >> exclusive lock held, and consider that repeated, failed data >> integration transactions are implicated in this in a big way when a >> problem appears in the wild. A big part of the problem here was that >> garbage collection did not run often enough. > > Hm. The problem I've got with this is that then mean_query_len means > something significantly different after entry_dealloc than it does > after gc_texts. > > I'd be okay with changing *both* of those functions to ignore sticky > entries in the calculation, if that seems reasonable to you. That seems perfectly reasonable, yes. Should I leave that to you? >> In other words, I'd be fine with *not* doing the query size filter >> thing for now, since that is something that seems like an extra >> defense and not core to the problem. I was kind of ambivalent about >> doing that part myself, actually. > > Agreed on that part. We're in full agreement on what needs to happen for the next point release, then. Excellent. -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
