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.
>
>
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
No comments:
Post a Comment