Peter Geoghegan <p...@heroku.com> writes:
> I'm not clear on what you actually propose to do to "make
> entry_dealloc's recomputation of mean_query_len sane", but I think you
> are talking about something distinct from what I've proposed
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'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.
> 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.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
