Re: Increasing the length of pg_stat_activity.current_query... - Mailing list pgsql-hackers

From Greg Stark
Subject Re: Increasing the length of pg_stat_activity.current_query...
Date
Msg-id 877joxl6il.fsf@stark.xeocode.com
Whole thread Raw
In response to Re: Increasing the length of pg_stat_activity.current_query...  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Increasing the length of  (Simon Riggs <simon@2ndquadrant.com>)
List pgsql-hackers
Tom Lane <tgl@sss.pgh.pa.us> writes:

> > I'd vote in favour of relaxing the limit entirely, as Sean suggests.
> 
> The choice is not between "limit" and "no limit", it is between
> "limit" and "broken".

What do you think is broken about fragmented UDP packets?

Once Upon a Time fragmented UDP packets basically didn't work at all. But
that's going on 20 years now. These days you can reliably send large packets
up to 32k certainly over local connections and even over long-haul connections
when you don't have packet loss problems. Even when you do the worst case
scenario is your packet doesn't make it, so what's the harm in at least trying
to send it?

I'm assuming the packets aren't a fixed size. As long as we aren't bumping up
the other packets to 8k then there's no danger to sending the occasional 8k
packet. 

The reason people don't like fragmented UDP packets is that there's no
retransmission facility and a packet is lost if a single fragment is lost. So
if you're sending an 8k packet with an MTU of 1500 you'll have 5 fragments.
With 10% packet loss that gives your 8k fragmented packet a 50/50 chance of
getting through.

But if you're having 10% packet loss on your local area network you already
have a problem. Even then you're losing 10% of your smaller queries and 50% of
your larger queries whereas currently you would be losing 10% of your smaller
queries and 100% of your larger queries...

-- 
greg



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: pg_resetxlog options
Next
From: Gaetano Mendola
Date:
Subject: Bittorrent