Re: [PATCH] Increase the maximum value track_activity_query_size - Mailing list pgsql-hackers

From Robert Haas
Subject Re: [PATCH] Increase the maximum value track_activity_query_size
Date
Msg-id CA+TgmoYX1QQAPz075kSF0Wqz4+QbmbPzn3A2DE8pPvOY0Ka-CQ@mail.gmail.com
Whole thread Raw
In response to Re: [PATCH] Increase the maximum value track_activity_query_size  (Jeff Janes <jeff.janes@gmail.com>)
Responses Re: [PATCH] Increase the maximum value track_activity_query_size  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Thu, Jan 2, 2020 at 3:27 PM Jeff Janes <jeff.janes@gmail.com> wrote:
> I've seen some pretty big IN-lists and VALUES lists.   They aren't so hard to debug once you tune out iterations 3
throughN-3 of the list members.  Unless they are hard to debug for other reasons.  In these cases, it would be helpful,
ifnot just allowing bigger texts in general, to instead "truncate" from the middle, preserving both the beginning and
theend of the query text. 

I vote for not trying to make this more complicated and just accepting
the original proposal. It's about a factor of ten increase over the
limit we have right now, which doesn't seem like enough to cause any
real breakage, and it should be enough to satisfy the majority of the
people who are unhappy with the current limit, and it is very little
work. If somebody wants to do more work on this later, they can, but I
don't think the OP should be on the hook for that.

At some point, someone (I think Peter Geoghegan) suggested that
pg_stat_statements ought to normalize IN lists down to a single
element. That kind of thing might be another approach to the problem
you mention. It's a bit easier to imagine doing such a thing from a
tool like that than it is to do it for strings in pg_stat_activity
because pg_stat_statements has got a parse tree to work with, not just
a flat sting. And that might work more nicely than just keeping the
beginning and end of the string, but of course it's also more
complicated, so I don't know.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Vik Fearing
Date:
Subject: Re: Greatest Common Divisor
Next
From: Robert Haas
Date:
Subject: Re: Greatest Common Divisor