(Responding to the deafening silence regarding my posts a couple of days
ago about logging dbnames and disconnections) ;-)
The dbname patch is now done. If nobody objects to the format
("[db:yourdbname]") I'll submit it - I did it that way to make it fairly
easy to split a log file based on it,
Not quite the same - timestamps and pids have known formats, while db
names are almost arbitrary. I know including spaces in names is horrible
to my *nix way of thinking, but others might not have my prejudices.
(interesting question - what characters are NOT allowed in a database
name?).
BTW,
Larry Rosenman <[EMAIL PROTECTED]> writes:
> --On Tuesday, August 05, 2003 16:27:55 -0400 Tom Lane <[EMAIL PROTECTED]>
>> A variant (which'd be okay with me) is to separate these fields with
>> tabs instead of spaces; then the rule for DBAs would be "don't allow
>> tabs in db/user names".
> Tabs
My issue is that I think there are reasonable people might want
username, dbname, hostname, host ip, and host port on the log lines.
This is the information that we currently report during a connection, if
enabled.
I have no problem adding those five booleans if people prefer booleans
--- my big
--On Tuesday, August 05, 2003 16:41:34 -0400 Tom Lane <[EMAIL PROTECTED]>
wrote:
Larry Rosenman <[EMAIL PROTECTED]> writes:
--On Tuesday, August 05, 2003 16:27:55 -0400 Tom Lane
<[EMAIL PROTECTED]>
A variant (which'd be okay with me) is to separate these fields with
tabs instead of spaces; then
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Adding several new variables is fine, but what do we call the hostname
> option if we already have log_hostname?
We've renamed GUC variables before for consistency. I'd opt
for picking names that show the common purpose, maybe log_line_FOO?
> I could see that being nice so you could create a couple of different
> custom log types, then use one for one database, and another for a
> different database.
Point them to different log files and you've got yourself a great
feature.
> For people running large numbers of databases on a si
Bruce Momjian <[EMAIL PROTECTED]> writes:
> ... And of course, we already have pid and timestamp, so once
> we are done, we will have seven possible data items on each line, and
> with booleans there will be no control over their order on the line.
Which is exactly the way I want it ;-). I can't
I think we need a more general variable that can take several values,
separated by commas, like:
log_line: dbname,user
or something like that.
In fact, looking at the postgresql.conf file, I see only two setting
that print on every line: log_pid and log_timestamp. Perhaps those two
s
Gathering some of the threads, here's what I see:
1. There is some demand for per database logging. Doing that is rather
beyond the scope of what I intended - in fact what I intended was to enable
sensible log splitting out of band. I'll even write a perl script to do it
for you if you like :-)
2
Tom,
> > I'm prepared to be guided by concensus, though.
>
> I'm not dead set on it either, just wanted to raise a flag. Who else
> has an opinion?
>From my perspective, we could really use a "delimiter" between the "fields" of
log output which is unlikely to appear within those fields instead
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> The dbname patch is now done. If nobody objects to the format
> ("[db:yourdbname]") I'll submit it - I did it that way to make it fairly
> easy to split a log file based on it, although you would have to be
> careful with multiline log entries such as
Another interesting idea, if we do a single log variable with parameters
separated by commas, is to allow some syntax where you could specify the
delimiter between fields, so it could be:
log_line: "|", dbname, username
or
log_line: " ", dbname, username
---
"Mendola Gaetano" <[EMAIL PROTECTED]> writes:
> "Tom Lane" <[EMAIL PROTECTED]> writes:
>> A variant (which'd be okay with me) is to separate these fields with
>> tabs instead of spaces; then the rule for DBAs would be "don't allow
>> tabs in db/user names".
> do you see: ^I that are "chars" th
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Josh Berkus <[EMAIL PROTECTED]> writes:
> > From my perspective, we could really use a "delimiter" between the
> > "fields" of log output which is unlikely to appear within those fields
> > instead of parsing by character count, rather than making dbname a
>
--On Tuesday, August 05, 2003 16:27:55 -0400 Tom Lane <[EMAIL PROTECTED]>
wrote:
Josh Berkus <[EMAIL PROTECTED]> writes:
From my perspective, we could really use a "delimiter" between the
"fields" of log output which is unlikely to appear within those fields
instead of parsing by character coun
On Tue, 5 Aug 2003, Andrew Dunstan wrote:
>
> (Responding to the deafening silence regarding my posts a couple of days
> ago about logging dbnames and disconnections) ;-)
>
> The dbname patch is now done. If nobody objects to the format
> ("[db:yourdbname]") I'll submit it - I did it that way
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> I'm prepared to be guided by concensus, though.
I'm not dead set on it either, just wanted to raise a flag. Who else
has an opinion?
regards, tom lane
---(end of broadcast)---
TI
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > ... And of course, we already have pid and timestamp, so once
> > we are done, we will have seven possible data items on each line, and
> > with booleans there will be no control over their order on the line.
>
> Which is exactly the
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Adding several new variables is fine, but what do we call the hostname
> > option if we already have log_hostname?
>
> We've renamed GUC variables before for consistency. I'd opt
> for picking names that show the common purpose, ma
If we're looking at this, we might want to look at how apache does it with
it's customlog feature. This allows you to first define custom log types,
then set them according to which virtual server you're setting up.
I could see that being nice so you could create a couple of different
custom l
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I think we need a more general variable that can take several values,
> separated by commas, like:
> log_line: dbname,user
> or something like that.
Strikes me as overkill --- adding two more booleans comparable to
log_pid would do the job just as
Josh Berkus <[EMAIL PROTECTED]> writes:
> From my perspective, we could really use a "delimiter" between the
> "fields" of log output which is unlikely to appear within those fields
> instead of parsing by character count, rather than making dbname a
> special case.
Well, Andrew was arguing that s
It's more work for a very small cosmetic benefit, ISTM. Setting up
atomic GUC variables is trivially easy, I'm happy to say. Not that I
can't write a simple parser, but why bother for something so tiny?
Also, would we be saying (or implying) that the order given on the line
would affect the ou
24 matches
Mail list logo
