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