From: Tom Lane <tgl@sss.pgh.pa.us>
To: Peter Geoghegan <pg@heroku.com>
cc: Jim Nasby <Jim.Nasby@bluetreble.com>,
 Pg Hackers <pgsql-hackers@postgresql.org>
Subject: Re: Less than ideal error reporting in pg_stat_statements
In-reply-to: 
 <CAM3SWZRH8=6P8=eicmOFAY+WROV_5giezZc=LnoUUtFYRYG0pg@mail.gmail.com>
References: <5601D354.5000703@BlueTreble.com>
 <CAM3SWZRo_5ZznTp=Mg5Kh2eq-LjWLVS-BXJwsHe_dS50g34Mfw@mail.gmail.com>
 <15898.1442965225@sss.pgh.pa.us>
 <CAM3SWZT41NeiK74J4PeKBA=rkML6-TR1pmj_ABf7Y6c8ihR+4A@mail.gmail.com>
 <CAM3SWZTOjkP9EJsaUcvhpHxXfdCyXbCcFuTDNT4Qct90ZMU8Hw@mail.gmail.com>
 <CAM3SWZTJEPY7A5HBJMB-s6rhZxk8LXiaxZPAMDytBpLs3P60Tw@mail.gmail.com>
 <CAM3SWZQBf6nepv2PKm_PDqwxUzxgzp5664bmRpq4AhSTM2UX_w@mail.gmail.com>
 <5913.1443822154@sss.pgh.pa.us>
 <CAM3SWZQjp_W4bZC=BgEQrP3EXrEnOzaytkJZbntdmZe8f2EOBQ@mail.gmail.com>
 <CAM3SWZTahp86i-5vDnfL5nzYCUjdmRu=sWRKXEZVd3E9dKGEFA@mail.gmail.com>
 <CAM3SWZTwNKkeCN+n_ew2eLFrWT9+UcPRLUTyy_xWN12QzGORsA@mail.gmail.com>
 <9935.1443828452@sss.pgh.pa.us>
 <CAM3SWZTZfwJRBv85XHcbc-TRhM4xsOD6fYfU3anF9WVTNeRUFw@mail.gmail.com>
 <32385.1443976035@sss.pgh.pa.us>
 <CAM3SWZRH8=6P8=eicmOFAY+WROV_5giezZc=LnoUUtFYRYG0pg@mail.gmail.com>
Comments: In-reply-to Peter Geoghegan <pg@heroku.com>
 message dated "Sun, 04 Oct 2015 12:41:40 -0700"
Date: Sun, 04 Oct 2015 16:01:13 -0400
Message-ID: <26165.1443988873@sss.pgh.pa.us>
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

Peter Geoghegan <pg@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