Re: Backend Stats Enhancement Request

Hi,

I'm new to the postgresql source, thought I'd try my hand at 
implementing the change suggested (i.e. the GUC-ification of the 
PGBE_ACTIVITY_SIZE constant) to get my hands dirty with the code.

How does this sound:

* A new GUC variable -- "activity_message_size" -- will be introduced
* The PGBE_ACTIVITY_SIZE #define becomes PGBE_DEFAULT_ACTIVITY_SIZE
* Minimum value of PGBE_DEFAULT_ACTIVITY_SIZE, maximum value of INT_MAX?

I'm struggling a little to come up with a decent description of the GUC 
variable -- something along the lines of "Sets the maximum length of 
backend status messages". Any suggestions?

Also: how should we allocate the memory for PgBackendStatus.st_activity? 
I'm guessing it's going to be necessary to keep this in shmem ...

Cheers,
T

David Miller wrote:
>> That's not where the problem is.  The people who will be left holding
>> the short end of the stick are the ones who can't raise their SHMMAX
>> setting past a couple of megabytes.
>>
>> It might be feasible to make pg_stat_activity's max string length
>> a postmaster-start-time configuration option.
>>     
>
> I am fine with a postmaster-start-time configuration option. It is not as flexible as I would like, but would serve
theimmediate need and keep me from having to 
 
> patch every release of Postgres we install on boxes.
>
> The load on our production servers really prohibits any kind of processing of the log files locally. We have tried
usingseveral log shipping methods to process the 
 
> logs on a machine with fewer running processes. These large queries are generated by a third party tool that we have
verylimited control over. Some of the queries 
 
> captured are as large 16K. The queries are poorly written/generated. 
>
>
>  David Miller
> River Systems, Inc.
>
>