Summary: | Use application_name | ||
---|---|---|---|
Product: | Slony-I | Reporter: | Christopher Browne <cbbrowne> |
Component: | slon | Assignee: | Christopher Browne <cbbrowne> |
Status: | RESOLVED FIXED | ||
Severity: | enhancement | CC: | slony1-bugs |
Priority: | low | ||
Version: | devel | ||
Hardware: | All | ||
OS: | All |
Description
Christopher Browne
2010-12-03 12:56:59 UTC
Note that this allows monitoring processes looking at the view pg_stat_activity to have a little more information as to "what's this process for?" Taking a peek at slon source code... -> % ack-grep slon_connectdb local_listen.c 57: if ((conn = slon_connectdb(rtcfg_conninfo, "local_listen")) == NULL) cleanup_thread.c 80: if ((conn = slon_connectdb(rtcfg_conninfo, "local_cleanup")) == NULL) remote_worker.c 370: if ((local_conn = slon_connectdb(rtcfg_conninfo, conn_symname)) == NULL) 2588: if ((pro_conn = slon_connectdb(conninfo, conn_symname)) == NULL) 3745: provider->conn = slon_connectdb(provider->pa_conninfo, remote_listen.c 208: conn = slon_connectdb(conn_conninfo, conn_symname); sync_thread.c 59: if ((conn = slon_connectdb(rtcfg_conninfo, "local_sync")) == NULL) slon.h 567:extern SlonConn *slon_connectdb(char *conninfo, char *symname); dbutils.c 47: * slon_connectdb 51:slon_connectdb(char *conninfo, char *symname) 71: "slon_connectdb: PQconnectdb(\"%s\") failed\n", 78: "slon_connectdb: PQconnectdb(\"%s\") failed - %s", 120: "slon_connectdb: PQconnectdb(\"%s\") PostgreSQL version not supported\n", The value of "conn_symname" looks to be pretty suitable as being most of the value to pass in. Values include: local_listen local_cleanup local_sync And within remote_worker.c: remoteWorkerThread_%d copy_set_%d subscriber_%d_provider_%d Added branch for development of this feature... Added function store_application_name(name) that checks to see if the GUC variable exists, and sets it, if so. Added a hook to slon_connectdb() that calls the function. https://github.com/cbbrowne/slony1-engine/commit/a2d97d94017e74b0fdad100f4be3b2327a56b29d Sample output on Postgres HEAD: testdb@localhost-> select datid, datname, procpid, application_name from pg_stat_activity where application_name like 'slon%'; datid | datname | procpid | application_name -------+---------------+---------+--------------------------- 44510 | slonyregress1 | 30969 | slon.local_listen 44510 | slonyregress1 | 30974 | slon.local_cleanup 44510 | slonyregress1 | 30975 | slon.local_sync 44573 | slonyregress2 | 30976 | slon.node_2_listen 44510 | slonyregress1 | 30977 | slon.remoteWorkerThread_2 (5 rows) Do much the same for slonik... https://github.com/cbbrowne/slony1-engine/commit/bbe9a3f0f7015768bf3fbc044d9a9bf14039859f https://github.com/cbbrowne/slony1-engine/commit/766acf3e105644878e19af8c1fa14f568f187341 Revise slonik handling of application_name... Query to see if the GUC is there, and only try to set the GUC if it actually exists in this database. In the first patch you add a stored function store_application_name() wouldn't it be better for your change to slonik to use this function instead of duplicating the logic? I realize that there is a bit of a chicken/egg situation here in that until slonik installs the slony schema the function doesn't exist so it can't be called. I am also not sure how I feel about querying the catalog pg_settings table for application name to see what version we are on. The other way of approaching this is to check the server version on from the pg connection data structures and not set the application name accordingly OR we can have a no-op implementation of store_application_name() for versions < 9.0. (In reply to comment #6) > In the first patch you add a stored function store_application_name() > wouldn't it be better for your change to slonik to use this function > instead of duplicating the logic? > > I realize that there is a bit of a chicken/egg situation here in that until > slonik installs the slony schema the function doesn't exist so it can't be > called. There lies the problem... slonik can't call it unless the function is already there. The alternative, I suppose, is to change the slon logic to duplicate the logic in slonik, so we don't need to have a version-specific stored function. > I am also not sure how I feel about querying the catalog pg_settings table for > application name to see what version we are on. The other way of approaching > this is to check the server version on from the pg connection data structures > and not set the application name accordingly OR we can have a no-op > implementation of store_application_name() for versions < 9.0. I'm uninterested in what version we are on; I am interested in whether or not Postgres supports the GUC "application_name". If we handle this feature that way, then we never have to ask what version it is tied to, because it doesn't matter. (In reply to comment #7) That argument makes sense. It seems fine to commit except for: - For the slonik change, even if PQntuples(res)==0 you still need to call PQclear(res) to free the structure (that contains zero tuples) or you have a small memory leak. You do this properly in the slon change. Added freeing of res in slonik.c... Squashed code into a commit to put into master: http://git.postgresql.org/gitweb?p=slony1-engine.git;a=commit;h=4ae9a212ccf6fe0bd52a4c015a39a251107405a5 |