Re: [PATCH] Increase the maximum value track_activity_query_size

Поиск
Список
Период
Сортировка
От Jeff Janes
Тема Re: [PATCH] Increase the maximum value track_activity_query_size
Дата
Msg-id CAMkU=1yUF+6ZdC05ytMGfpzCw+07xVmtOn0eOyENVrW9S+Di7Q@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [PATCH] Increase the maximum value track_activity_query_size  (Andrew Dunstan <andrew.dunstan@2ndquadrant.com>)
Ответы Re: [PATCH] Increase the maximum value track_activity_query_size  (Robert Haas <robertmhaas@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Christoph Moench-Tegeder
Дата:
Сообщение: Re: Recognizing superuser in pg_hba.conf
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Recognizing superuser in pg_hba.conf