| From: | "Gauthier, Dave" <dave(dot)gauthier(at)intel(dot)com> |
|---|---|
| To: | "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> |
| Subject: | Can I track DB connections through a generic acct on the basis of linux idsid |
| Date: | 2011-11-01 01:23:14 |
| Message-ID: | 482E80323A35A54498B8B70FF2B8798004D5BD8915@azsmsx504.amr.corp.intel.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
Hi:
PG v8.3.4 on linux. Server is at one corporate site, half the DB users are at that site, the other half are at a different site 2 time zones away. Users from both sites access the DB through the same, generic postgres user accout that has select/insert/update/delete only. And almost all of this is through perl scripts that use DBI as a gateway into the PG DB.
I want to be able to determine who ran what script and from what user site. All this info is at my fingertips during the execution of the perl script. I would like to ba able to log this info immediately before or after the DB connection, not wait for the transaction or query to complete. I would prefer not to have to insert this info to a log table because that would mean waiting for an additional network hit for simple queries from the remote site.
Is there a way to pass the info (idsid, app, site) to the perl/dbi connection string and get this info reported in the deamon runlog somehow?
How about "raise notice"? Could that be made to work somehow?
OK, having said all that, a completely different tact... There are 1468 potential users (idsids) out there that can query the DB. Does it make sense to create a DB user for each of those, giving them all the same access through a role or something, and then attacking the problem from that direction? Is 1468 impractical?
Thanks in advance!
| From | Date | Subject | |
|---|---|---|---|
| Next Message | daflmx | 2011-11-01 01:58:25 | |
| Previous Message | Roger Niederland | 2011-11-01 01:02:35 | variable not found in subplan target list |