Re: Less than ideal error reporting in pg_stat_statements - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: Less than ideal error reporting in pg_stat_statements
Date
Msg-id CAM3SWZT41NeiK74J4PeKBA=rkML6-TR1pmj_ABf7Y6c8ihR+4A@mail.gmail.com
Whole thread Raw
In response to Re: Less than ideal error reporting in pg_stat_statements  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Less than ideal error reporting in pg_stat_statements  (Peter Geoghegan <pg@heroku.com>)
Re: Less than ideal error reporting in pg_stat_statements  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Re: Less than ideal error reporting in pg_stat_statements  (Marti Raudsepp <marti@juffo.org>)
List pgsql-hackers
On Tue, Sep 22, 2015 at 4:40 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> I wonder whether the real problem here is failure to truncate statement
> texts to something sane.  Do we really need to record the whole text of
> multi-megabyte statements?  Especially if doing so could render the entire
> feature nonfunctional?

I recently encountered a 9.4 customer database that had an insanely
large query text stored by pg_stat_statements, apparently created as
part of a process of kicking the tires of their new installation. I
don't know how large it actually was, but it caused psql to stall for
over 10 seconds. Insane queries happen, so truncating query text could
conceal the extent of how unreasonable a query is.

I think that the real problem here is that garbage collection needs to
deal with OOM more appropriately. That's the only way there could be a
problem with an in-flight query as opposed to a query that looks at
pg_stat_statements, which seems to be Nasby's complaint.

My guess is that this very large query involved a very large number of
constants, possibly contained inside an " IN ( )". Slight variants of
the same query, that a human would probably consider to be equivalent
have caused artificial pressure on garbage collection.

-- 
Peter Geoghegan



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Rework the way multixact truncations work
Next
From: Robert Haas
Date:
Subject: Re: Parallel Seq Scan