Re: [PATCH] Increase the maximum value track_activity_query_size

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
Cc: Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, Robert Treat <rob(at)xzilla(dot)net>, Nikolay Samokhvalov <samokhvalov(at)gmail(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, Bruce Momjian <bruce(at)momjian(dot)us>, Alexey Kondratov <a(dot)kondratov(at)postgrespro(dot)ru>, v(dot)makarov(at)postgrespro(dot)ru, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: [PATCH] Increase the maximum value track_activity_query_size
Date: 2020-01-03 18:36:01
Message-ID: CA+TgmoYX1QQAPz075kSF0Wqz4+QbmbPzn3A2DE8pPvOY0Ka-CQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Jan 2, 2020 at 3:27 PM Jeff Janes <jeff(dot)janes(at)gmail(dot)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 through N-3 of the list members. Unless they are hard to debug for other reasons. In these cases, it would be helpful, if not just allowing bigger texts in general, to instead "truncate" from the middle, preserving both the beginning and the end 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2020-01-03 18:46:01 Re: Greatest Common Divisor
Previous Message Vik Fearing 2020-01-03 18:34:55 Re: Greatest Common Divisor