From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: TODO list |
Date: | 2004-01-06 19:23:57 |
Message-ID: | 3FFB0B4D.40203@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Bruce Momjian wrote:
>Andrew Dunstan wrote:
>
>
>>I thought we had thrashed this out back in August. Certainly the only
>>thing I recall seeing after I submitted the patch was some stylistic
>>criticism from Neil, which I addressed in a revised patch.
>>
>>Anyway, it is in principle doable. That's partly why I adopted a printf
>>style format string. There are some wrinkles, though:
>>. interaction with syslog pid/timestamp logging
>>
>>
>
>Yes. If you use syslog, just don't ask for pid/timestamp and let syslog
>do it. Of course, right now we are able to send non-pid/timestamp to
>syslog _and_ send pid/timestamp to a log file, but that seems like a
>rare operation that doesn't justify keeping the various log parameters
>separate.
>
I'm OK with that as long as it is the consensus view. It does seem a
little odd to remove functionality (however rare) for the sake of
configuration neatness, though.
>
>Also, I would like to see some kind of session identifier that is more
>unique than pid, which wraps around. Ideally we could have 10{pid},
>then then the pid wraps around, 20{pid), or something like that.
>
This requires some thought. ISTM it wouldn't buy you much unless you
made it persistent across server restarts, and possibly not even then. I
don't see it as a reason to hold up these features, though. If someone
wants to tackle this it could be plugged in to the loginfo feature very
easily as an extra escape sequence.
>
>
>
>>. making sure the info is available when you need to log it - I had to
>>rearrange a few thing to avoid getting SEGVs, IIRC.
>>
>>
>
>Of course some messages, like postmaster status messages, don't have
>some of these fields, like username or host. Is that going to cause
>problems for tools that read our log files?
>
If users want a non-empty info string they will have to teach the tools
to handle it anyway. The point was, however, that rolling up PID and
timestamp into the printf-style format will require some significant
work, because we wouldn't want to lose that info if the user/db weren't
known, whereas the patch currently suppresses all log-info output if
these are not present (i.e. when MyProcPort == NULL).
>
>
>
>>Also, the session duration logging part of the patch is orthogonal to the
>>issue.
>>
>>
>
>You mean query duration? Yes, it is orthoginal.
>
>
No, I meant the logging of the end of a session, including its duration,
which was also in the patch.
cheers
andrew
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2004-01-06 19:36:05 | Reserved words and named function parameters |
Previous Message | Josh Berkus | 2004-01-06 19:21:01 | Re: Proposed Query Planner TODO items |