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

From Jeff Janes
Subject Re: [PATCH] Increase the maximum value track_activity_query_size
Date
Msg-id CAMkU=1yUF+6ZdC05ytMGfpzCw+07xVmtOn0eOyENVrW9S+Di7Q@mail.gmail.com
Whole thread Raw
In response to Re: [PATCH] Increase the maximum value track_activity_query_size  (Andrew Dunstan <andrew.dunstan@2ndquadrant.com>)
Responses Re: [PATCH] Increase the maximum value track_activity_query_size  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Mon, Dec 30, 2019 at 6:46 PM Andrew Dunstan <andrew.dunstan@2ndquadrant.com> wrote:
On Tue, Dec 31, 2019 at 9:38 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:

>
> This doesn't seem like a reason not to allow a higher limit, like a
> megabyte or so, but I'm not sure that pushing it to the moon would be
> wise.
>


Just to get a mental handle on the size of queries we might be
allowing before truncation, I did some very rough arithmetic on what
well known texts might fit in a megabyte. By my calculations you could
fit about four Animal Farms or one Madame Bovary in about a megabyte.
So I think that seems like more than enough :-). (My mind kinda
explores at the thought of debugging a query as long as Animal Farm.)


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.

Cheers,

Jeff

pgsql-hackers by date:

Previous
From: Christoph Moench-Tegeder
Date:
Subject: Re: Recognizing superuser in pg_hba.conf
Next
From: Tom Lane
Date:
Subject: Re: Recognizing superuser in pg_hba.conf