From: | Vladimir Sitnikov <sitnikov(dot)vladimir(at)gmail(dot)com> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Subject: | Configurable length of application_name and/or read access to custom gucs of another backend |
Date: | 2015-10-20 19:10:16 |
Message-ID: | CAB=Je-Eej9Um5_E_z1vY1sBVgH5aLm=Hy=DsKnAo0gdMVFz2qA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Hi,
I want to instrument database connections with app
module/action/username/transaction id/etc.
The main use case is for troubleshooting purposes:
1) I want some kind of report from the database (e.g. select * from
pg_stat_activitiy) to show not just SQL texts, but application
modules/components as well
2) In case of connection leak, it would be nice to know where the
connection was last used
application_name is limited with 64 characters (or bytes?), so it is
not sufficient to store the ids.
What is the recommended way of solving that?
I'm afraid, I cannot ask clients recompiling postgresql for changing namelen.
Can the length of application_name be configurable via regular
configuration parameter?
Is there a way to read guc from another backend?
Can we have more fields like "application_name"?
For instance, there is a paper on distributed tracing (see [1]) that
suggests having a couple of 64-bit ids to identify the call (span id
and parent span id).
I know there are security/concurrency implications, so I wonder if
there are hard limits.
In the mean time, my workaround would be unlogged table like
app_connection_tracker(pid, app_user, module, action, ...) with index
on pid.
Any pitfalls with that kind of "update mostly table"?
[1]: http://research.google.com/pubs/pub36356.html
--
Regards,
Vladimir Sitnikov
From | Date | Subject | |
---|---|---|---|
Next Message | Vick Khera | 2015-10-20 19:56:14 | Re: Returning JSON or JSONB |
Previous Message | Merlin Moncure | 2015-10-20 19:09:45 | Re: RAID and SSD configuration question |