Re: [HACKERS] [PATCHES] WIP patch - INSERT-able log statements

2007-02-20 Thread Greg Smith
On Tue, 20 Feb 2007, Tom Lane wrote: I can't believe that any production situation could tolerate the overhead of one-commit-per-log-line. There aren't that many log lines, and a production environment with lots of commit throughput won't even notice. The installation I work on tuning does

Re: [HACKERS] [PATCHES] WIP patch - INSERT-able log statements

2007-02-19 Thread Guillaume Smet
On 2/19/07, Alvaro Herrera [EMAIL PROTECTED] wrote: Guillaume Smet escribió: On 2/19/07, Alvaro Herrera [EMAIL PROTECTED] wrote: So add the session ID (%c) to log_line_prefix. It could work if log_line_prefix was added before every line but it's definitely not the case: myuser mydb

Re: [HACKERS] [PATCHES] WIP patch - INSERT-able log statements

2007-02-19 Thread Alvaro Herrera
Guillaume Smet escribió: On 2/19/07, Alvaro Herrera [EMAIL PROTECTED] wrote: Guillaume Smet escribió: On 2/19/07, Alvaro Herrera [EMAIL PROTECTED] wrote: So add the session ID (%c) to log_line_prefix. It could work if log_line_prefix was added before every line but it's definitely not

Re: [HACKERS] [PATCHES] WIP patch - INSERT-able log statements

2007-02-19 Thread Guillaume Smet
On 2/19/07, Alvaro Herrera [EMAIL PROTECTED] wrote: If it adds necessary context then it clear does not have the same behavior, I mean log_line_prefix behaviour is the same. The other information are syslog specific. I'd propose adding a log_entry_prefix separate from log_line_prefix; the

Re: [HACKERS] [PATCHES] WIP patch - INSERT-able log statements

2007-02-19 Thread Greg Smith
On Mon, 19 Feb 2007, Guillaume Smet wrote: Why not simply put something like %log_table% in the sql file and let the admin replace it with sed or whatever he likes? This is a reasonable approach. I would suggest that no special characters be used though, so that the SQL could be used as-is

Re: [HACKERS] [PATCHES] WIP patch - INSERT-able log statements

2007-02-19 Thread Greg Smith
On Mon, 19 Feb 2007, Alvaro Herrera wrote: We already have a combined GUC option that is used to change two different things (DateStyle) and I regularly see people confused about how to use it. You already have a combined GUC option called log_destination that's sitting in the appropriate

Re: [HACKERS] [PATCHES] WIP patch - INSERT-able log statements

2007-02-19 Thread Tom Lane
Greg Smith [EMAIL PROTECTED] writes: A workable syntax might be INSERT INTO pg_log ... Why is this still under discussion? I thought we'd agreed that COPY format was the way to go. regards, tom lane ---(end of

Re: [HACKERS] [PATCHES] WIP patch - INSERT-able log statements

2007-02-19 Thread Tom Lane
Greg Smith [EMAIL PROTECTED] writes: On Mon, 19 Feb 2007, Alvaro Herrera wrote: Also, sql is not really a destination -- it is a format. A log file with a different name is another destination. eventlog is certainly a different format and it's sitting happily as an option there. I haven't

Re: [HACKERS] [PATCHES] WIP patch - INSERT-able log statements

2007-02-19 Thread Greg Smith
On Mon, 19 Feb 2007, Tom Lane wrote: Why is this still under discussion? I thought we'd agreed that COPY format was the way to go. Joshua Drake said COPY would be a good option, but INSERT is probably what I would use as the default. The most use I see for this is something where I am

Re: [HACKERS] [PATCHES] WIP patch - INSERT-able log statements

2007-02-19 Thread Tom Lane
Greg Smith [EMAIL PROTECTED] writes: The arguments for COPY are performance and that you don't need to specify the table name. INSERT is slower and you need a name, but it's easier to build a UNIX tool style pipeline to import it in real-time. I can't believe that any production situation

Re: [HACKERS] [PATCHES] WIP patch - INSERT-able log statements

2007-02-18 Thread Guillaume Smet
Added -hackers to CC:. On 2/18/07, Greg Smith [EMAIL PROTECTED] wrote: I've thought a bit about how to implement this TODO already (I have a log file parser and I hate maintaining it) Any problem using pgFouine? Also, I feel that supporting the whole log_line_prefix syntax for this feature