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 ...
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
pgsql-hackers by date
|Next:||From: Gaetano Mendola||Date: 2008-06-20 09:52:03|
|Subject: Not valid dump [8.2.9, 8.3.1]|
|Previous:||From: Deepak||Date: 2008-06-20 07:40:30|
|Subject: ...Roll Back issue in PGSQL..|