Re: Increasing the length of pg_stat_activity.current_query...
От | Greg Stark |
---|---|
Тема | Re: Increasing the length of pg_stat_activity.current_query... |
Дата | |
Msg-id | 878y9cj8x9.fsf@stark.xeocode.com обсуждение исходный текст |
Ответ на | Re: Increasing the length of pg_stat_activity.current_query... (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Increasing the length of pg_stat_activity.current_query...
Re: Increasing the length of pg_stat_activity.current_query... |
Список | pgsql-hackers |
Tom Lane <tgl@sss.pgh.pa.us> writes: > Greg Stark <gsstark@mit.edu> writes: > > The pgstat messages are indeed fixed size. > > No, there's a fixed maximum size. Hm. *rereads source* It's true, pgstat_report_activity only sends the actual size of the query, not the full payload size. The only problem I see in raising the size of PGSTAT_MSG_PAYLOAD is that it also governs the size of PGSTAT_NUM_TABPURGE and PGSTAT_NUM_TABENTRIES. There's no need to grow those arrays and risk losing them. But these message sizes could just be left based on the 1k value while boosting the maximum size of PGSTAT_ACTIVITY_SIZE. 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. Shorter queries and other packets would be unaffected. -- greg
В списке pgsql-hackers по дате отправления: