Application name patch - v2
in [PgSql]
|
Prev: Hot standby status
Next: per table random-page-cost?
From: Bruce Momjian on 20 Oct 2009 01:22 Robert Haas wrote: > > I do agree with Peter's concerns about limiting the character set of the > > name string, and maybe there should be some sort of length limit too. > > I don't have a strong feeling about this. If limiting this to 7-bit > characters solves some nasty encoding problems or something, then > fine, but otherwise I think we can just escape what we emit into the > log and say that users who log this information should have a > sufficiently sophisticated log parser to cope with it. Once problem I can imagine is someone with a long log_line prefix, like '%t %a|', and assuming that the pipe is the end of the log_prefix arguments. If someone adds a pipe to the application name, log parsing code will assume the %a pipe ends the log_line_prefix, and we have no system of escaping things like pipes in log_line_prefix. Effectively, if you use %a, there is no good way to terminate log_line_prefix with a known unique character. -- Bruce Momjian <bruce(a)momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- 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: Magnus Hagander on 20 Oct 2009 02:47 2009/10/20 Bruce Momjian <bruce(a)momjian.us>: > Robert Haas wrote: >> > I do agree with Peter's concerns about limiting the character set of the >> > name string, and maybe there should be some sort of length limit too. >> >> I don't have a strong feeling about this. If limiting this to 7-bit >> characters solves some nasty encoding problems or something, then >> fine, but otherwise I think we can just escape what we emit into the >> log and say that users who log this information should have a >> sufficiently sophisticated log parser to cope with it. > > Once problem I can imagine is someone with a long log_line prefix, like > '%t %a|', and assuming that the pipe is the end of the log_prefix > arguments. If someone adds a pipe to the application name, log parsing > code will assume the %a pipe ends the log_line_prefix, and we have no > system of escaping things like pipes in log_line_prefix. > > Effectively, if you use %a, there is no good way to terminate > log_line_prefix with a known unique character. If you're going to parse your logfile, you should probably be using CSV format logs, which I believe would not have this issue... -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- 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: Dave Page on 20 Oct 2009 03:51 On Mon, Oct 19, 2009 at 9:34 PM, Magnus Hagander <magnus(a)hagander.net> wrote: > 2009/10/19 Dave Page <dpage(a)pgadmin.org>: >> On Mon, Oct 19, 2009 at 3:42 PM, Massa, Harald Armin <chef(a)ghum.de> wrote: >>> >>> Would'nt this also make sense for PostgreSQL? That is, when no environment >>> is set, and no SET-command is issued, that the application name becomes the >>> default? >> >> That needs to be set by the application. As discussed previously, >> there's no way for libpq to get at argv[0]. > > Um, that has to be platform dependent, no? On windows for example, you > can use GetCommandLine(). Yeah, and there's a similar API on *BSD I believe, but nothing standard. -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com PGDay.EU 2009 Conference: http://2009.pgday.eu/start -- 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: Magnus Hagander on 20 Oct 2009 03:53 2009/10/20 Dave Page <dpage(a)pgadmin.org>: > On Mon, Oct 19, 2009 at 9:34 PM, Magnus Hagander <magnus(a)hagander.net> wrote: >> 2009/10/19 Dave Page <dpage(a)pgadmin.org>: >>> On Mon, Oct 19, 2009 at 3:42 PM, Massa, Harald Armin <chef(a)ghum.de> wrote: >>>> >>>> Would'nt this also make sense for PostgreSQL? That is, when no environment >>>> is set, and no SET-command is issued, that the application name becomes the >>>> default? >>> >>> That needs to be set by the application. As discussed previously, >>> there's no way for libpq to get at argv[0]. >> >> Um, that has to be platform dependent, no? On windows for example, you >> can use GetCommandLine(). > > Yeah, and there's a similar API on *BSD I believe, but nothing standard. Right, but it might be worth investigating using the API that's available on the platform, if one is. It's a fairly simple operation after all, so it won't take huge amounts of platform-specific code. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- 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: Tom Lane on 20 Oct 2009 10:40
Magnus Hagander <magnus(a)hagander.net> writes: > 2009/10/20 Dave Page <dpage(a)pgadmin.org>: >> Yeah, and there's a similar API on *BSD I believe, but nothing standard. > Right, but it might be worth investigating using the API that's > available on the platform, if one is. It's a fairly simple operation > after all, so it won't take huge amounts of platform-specific code. It would be a seriously bad idea for this to behave one way on some platforms and differently on others. 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 |