Application name patch - v4
in [PgSql]
|
Prev: Backup history file should be replicated in Streaming Replication?
Next: [PATCH] hstore documentation update
From: Tom Lane on 29 Nov 2009 20:20 Fujii Masao <masao.fujii(a)gmail.com> writes: > Why doesn't application_name appear in postgresql.conf.sample? > That is expected to be set from only libpq? It would seem pretty silly to set it in the conf file. You *can*, if you want, but I see no reason to list it there. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Fujii Masao on 29 Nov 2009 21:21 On Mon, Nov 30, 2009 at 10:20 AM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > Fujii Masao <masao.fujii(a)gmail.com> writes: >> Why doesn't application_name appear in postgresql.conf.sample? >> That is expected to be set from only libpq? > > It would seem pretty silly to set it in the conf file. You *can*, > if you want, but I see no reason to list it there. Yeah, I see your point. But, is it a policy not to put such parameter (other than that for debug) on postgresql.conf.sample? Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Fujii Masao on 29 Nov 2009 22:20 On Mon, Nov 30, 2009 at 11:21 AM, Fujii Masao <masao.fujii(a)gmail.com> wrote: > On Mon, Nov 30, 2009 at 10:20 AM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: >> Fujii Masao <masao.fujii(a)gmail.com> writes: >>> Why doesn't application_name appear in postgresql.conf.sample? >>> That is expected to be set from only libpq? >> >> It would seem pretty silly to set it in the conf file. You *can*, >> if you want, but I see no reason to list it there. > > Yeah, I see your point. But, is it a policy not to put such parameter > (other than that for debug) on postgresql.conf.sample? Ooops! I missed GUC_NOT_IN_SAMPLE parameters. Sorry for noise. Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Andres Freund on 30 Nov 2009 02:20 Hi, On Monday 30 November 2009 01:16:43 Florian G. Pflug wrote: > Tom Lane wrote: > > : One possibility would be to make it possible to issue SETs that > > > > behave : as if set in a startup packet - imho its an implementation > > detail that : SET currently is used. > > > > I think there's a good deal of merit in this, and it would't be hard > > at all to implement, seeing that we already have SET LOCAL and SET > > SESSION. We could add a third keyword, say SET DEFAULT, that would > > have the behavior of setting the value in a fashion that would > > persist across resets. I'm not sure that DEFAULT is exactly le mot > > juste here, but agreeing on a keyword would probably be the hardest > > part of making it happen. > Hm, but without a way to prevent the users of a connection pool from > issuing "SET DEFAULT", that leaves a connection pool with no way to > revert a connection to a known state. Perhaps we should only allow a few parameters to be SET as a connection default - then the pooler would have to issue those just as it has to do for actual connection defaults. > How about "SET CONNECTION", with an additional GUC called > connection_setup which can only be set to true, never back to false. > Once connection_setup is set to true, further SET CONNECTION attempts > would fail. How would that help the pooler case? The next connection to it might be from a different application. Andres -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Dimitri Fontaine on 30 Nov 2009 16:11
Le 30 nov. 2009 à 00:25, Tom Lane a écrit : > The thing is that the libpq API treats application_name as a *property > of the connection*. Oh. Yeah. > We could add a third keyword, say SET DEFAULT, that would have the > behavior of setting the value in a fashion that would persist across > resets. I'm not sure that DEFAULT is exactly le mot juste here, but > agreeing on a keyword would probably be the hardest part of making it > happen. I vaguely remember you explaining how hard it would be to be able to predict the value we RESET to as soon as we add this or that possibility. That's very vague, sorry, but only leaves a bad impression on the keyword choice (bikeshedding, I should open a club). So what about SET CONNECTION application_name TO 'whatever'? Regards, -- dim -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |