Re: [PATCH] Increase the maximum value track_activity_query_size

From: Alexey Kondratov <a(dot)kondratov(at)postgrespro(dot)ru>
To: Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, 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: 2019-12-20 11:35:37
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On 19.12.2019 20:52, Robert Haas wrote:
> On Thu, Dec 19, 2019 at 10:59 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Bruce Momjian <bruce(at)momjian(dot)us> writes:
>>> Good question. I am in favor of allowing a larger value if no one
>>> objects. I don't think adding the min/max is helpful.
>> The original poster.

And probably anyone else, who debugs stuck queries of yet another crazy
ORM. Yes, one could use log_min_duration_statement, but having a
possibility to directly get it from pg_stat_activity without eyeballing
the logs is nice. Also, IIRC log_min_duration_statement applies only to
completed statements.

> I think there are pretty obvious performance and memory-consumption
> penalties to very large track_activity_query_size values. Who exactly
> are we really helping if we let them set it to huge values?
> (wanders away wondering if we have suitable integer-overflow checks
> in relevant code paths...)

The value of pgstat_track_activity_query_size is in bytes, so setting it
to any value below INT_MAX seems to be safe from that perspective.
However, being multiplied by NumBackendStatSlots its reasonable value
should be far below INT_MAX (~2 GB).

Sincerely, It does not look for me like something badly needed, but
still. We already have hundreds of GUCs and it is easy for a user to
build a sub-optimal configuration, so does this overprotection make sense?


Alexey Kondratov

Postgres Professional
Russian Postgres Company

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Prabhat Sahu 2019-12-20 11:46:50 Re: [HACKERS] Block level parallel vacuum
Previous Message Jehan-Guillaume de Rorthais 2019-12-20 10:14:28 Re: Fetching timeline during recovery