Re: Increasing the length of pg_stat_activity.current_query...

Greg Stark <gsstark(at)mit(dot)edu> writes:
> That would have no downside and only benefits. The worst case is that a
> machine that didn't handle UDP fragment reassembly would drop the packets that
> postgres is currently dropping preemptively.

Huh? We're not dropping the query *entirely*, which is what I would
expect to happen if the kernel doesn't want to deal with UDP packet
fragmentation.

However, after rereading the RFCs I think this discussion may be based
on false premises. In a network stack designed per the RFCs, both TCP
and UDP use the same IP-level fragmentation logic, and so it's unlikely
that there would be no fragmentation support at all. It's really a
performance issue: do you want to pay the penalty associated with
reassembling messages that exceed the loopback MTU, and do you want to
risk the possibility that the kernel will drop stuff on the floor rather
than fragment or reassemble it? Remember that UDP is non-guaranteed
delivery, and the cases you are most interested in are likely to be
exactly the same cases where the kernel is under stress and may decide
to shed load that way.

BTW, although the transmitted packets might not be fixed-size, the
per-backend entries written to the stats file are. Cranking
PGSTAT_ACTIVITY_SIZE up to the moon without loss of performance
will take more than just changing one #define.

Another relevant question is why you are expecting to get this
information through pgstats and not by looking in the postmaster log.
I don't know about you, but I don't have any tools that are designed to
cope nicely with looking at tables that have columns that might be many
K wide. Looking in the log seems a much nicer way of examining the full
text of extremely long queries. So I think it's actually a good thing
that pgstats truncates the queries at some reasonable width.

regards, tom lane