Skip site navigation (1) Skip section navigation (2)

Re: Backend Stats Enhancement Request

From: Thomas Lee <tom(at)vector-seven(dot)com>
To: David Miller <miller392(at)yahoo(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Backend Stats Enhancement Request
Date: 2008-06-20 09:36:02
Message-ID: 485B7A02.3060708@vector-seven.com (view raw or flat)
Thread:
Lists: pgsql-hackers
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 the immediate 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 using several 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 very limited control over. Some of the queries 
> captured are as large 16K. The queries are poorly written/generated. 
>
>
>  David Miller
> River Systems, Inc.
>
>   


In response to

Responses

pgsql-hackers by date

Next:From: Gaetano MendolaDate: 2008-06-20 09:52:03
Subject: Not valid dump [8.2.9, 8.3.1]
Previous:From: DeepakDate: 2008-06-20 07:40:30
Subject: ...Roll Back issue in PGSQL..

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group