Tomas Vondra <tomas.vondra@2ndquadrant.com> writes:
> 2) What's the overhead for increasing the value for short/long queries?
> My assumption is that for short queries, it's going to be negligible.
> For longer queries it may be measurable, but I'd expect longer queries
> to be more expensive in general, so maybe it's still negligible.
The thing that has been bothering me is the idea that backends reading
st_activity_raw might palloc the max possible length and/or memcpy the
whole buffer rather than just the valid part. Having now rooted through
pgstat.c, that appears to be half true: the local allocation made by
pgstat_read_current_status() will be just as large as the shared-memory
arena, but we use strcpy() or equivalent so that each query copy should
stop upon hitting a '\0'. So the run-time cost should be negligible, but
you might be eating a lot of memory if multiple sessions are inspecting
pg_stat_activity and you cranked the setting up imprudently high.
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.
Meanwhile, I noted what seems like a pretty obvious bug in
pg_stat_get_backend_activity():
clipped_activity = pgstat_clip_activity(activity);
ret = cstring_to_text(activity);
pfree(clipped_activity);
We're not actually applying the intended clip to the returned
value, so that an invalidly-encoded result is possible.
(Of course, since we also don't seem to be making any attempt
to translate from the source backend's encoding to our own,
there's more problems here than just that.)
regards, tom lane
