Alvaro Herrera <[EMAIL PROTECTED]> writes:
> I still propose that the log line number should be moved w.r.t. session
> identifier.
No objection here.
> I changed two more things: the VXID is not reported if not in a backend
> (because AuxiliaryProcesses are said to never have one), and added
> qu
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > Another change I did was to change a "%.*s" to "%*s". The "precision"
> > marker seems useless AFAICT.
>
> This is wrong, broken, will cause crashes on platforms where the PS
> string is not null-terminated. (Hint: .* is a maximum
Alvaro Herrera wrote:
>
> Another problem I just noticed is that it seems the bgwriter is
> inheriting the session id from Postmaster; it doesn't have one of its
> own.
Huh, sorry, I'm just blind, I neglected to look at the last digit ;-)
--
Alvaro Herrera Valdivia, Chile ICBM: S 39º 49
Another problem I just noticed is that it seems the bgwriter is
inheriting the session id from Postmaster; it doesn't have one of its
own.
--
Alvaro Herrera Developer, http://www.PostgreSQL.org/
"People get annoyed when you try to debug them." (Larry Wall)
Hmm, I'm now wondering if the log line number is correctly positioned.
Right now we have it just after the PID. So it suggests that following
PID and log line number is enough for tracking what a session does.
While this is not entirely incorrect, ISTM to be more logical to put it
closer to the se
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Another change I did was to change a "%.*s" to "%*s". The "precision"
> marker seems useless AFAICT.
This is wrong, broken, will cause crashes on platforms where the PS
string is not null-terminated. (Hint: .* is a maximum width, * is a
minimum width.
Tom Lane wrote:
> Andrew Dunstan <[EMAIL PROTECTED]> writes:
> > If it's about what to quote, we need to quote anything that might
> > contain a newline, quote or comma. Filenames certainly come into that
> > category.
>
> These are not general file paths, these are base names of our own C
> sourc
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> If it's about what to quote, we need to quote anything that might
> contain a newline, quote or comma. Filenames certainly come into that
> category.
These are not general file paths, these are base names of our own C
source code files. I don't have a
Alvaro Herrera wrote:
> Andrew Dunstan wrote:
>
> > Not sure I understand what this comment I noticed on a very brief glance is
> > about:
> >
> > /* assume no newlines in funcname or filename... */
> >
> > If it's about what to quote, we need to quote anything that might contain a
> > newline,
Andrew Dunstan wrote:
> Not sure I understand what this comment I noticed on a very brief glance is
> about:
>
> /* assume no newlines in funcname or filename... */
>
> If it's about what to quote, we need to quote anything that might contain a
> newline, quote or comma. Filenames certainly com
Alvaro Herrera wrote:
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
Well, if we want to cram all that stuff in there, how shall we do it?
It seems wrong to put all those lines into one text field, but I'm
not sure I want to add six more text fields
Tom Lane wrote:
> Andrew Dunstan <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> Well, if we want to cram all that stuff in there, how shall we do it?
> >> It seems wrong to put all those lines into one text field, but I'm
> >> not sure I want to add six more text fields to the CSV format
> >>
Alvaro Herrera wrote:
Andrew Dunstan wrote:
OK, works for me. I'll try to look at it after I have attended to the
Windows build issues. My plate is pretty full right now, though.
FYI I'm having a look at it now.
Great. Thanks.
cheers
andrew
---(end o
Andrew Dunstan wrote:
> OK, works for me. I'll try to look at it after I have attended to the
> Windows build issues. My plate is pretty full right now, though.
FYI I'm having a look at it now.
--
Alvaro Herrera http://www.amazon.com/gp/registry/CTMLCN8V17R4
"Llegará una época
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
One issue here is that CONTEXT is potentially multiple lines. I'm not
sure that there is much we can do about that, especially not at the last
minute. If we had some time to rewrite internal APIs it might be
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> One issue here is that CONTEXT is potentially multiple lines. I'm not
>> sure that there is much we can do about that, especially not at the last
>> minute. If we had some time to rewrite internal APIs it might be fun to
>> think abo
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
Well, if we want to cram all that stuff in there, how shall we do it?
It seems wrong to put all those lines into one text field, but I'm
not sure I want to add six more text fields to the CSV format
either. Th
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Well, if we want to cram all that stuff in there, how shall we do it?
>> It seems wrong to put all those lines into one text field, but I'm
>> not sure I want to add six more text fields to the CSV format
>> either. Thoughts?
> Reall
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
I can't see any very good reason for text logs to have different
content from CSV logs.
Well, if we want to cram all that stuff in there, how shall we do it?
It seems wrong to put all those lines into one text field, but I'm
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> I can't see any very good reason for text logs to have different
> content from CSV logs.
Well, if we want to cram all that stuff in there, how shall we do it?
It seems wrong to put all those lines into one text field, but I'm
not sure I want to add si
Tom Lane wrote:
"depesz" <[EMAIL PROTECTED]> writes:
Description:csvlog skips some logs
The point here is that CSV-format log output doesn't include the
DETAIL, HINT, or context (QUERY/STATEMENT/CONTEXT) lines that
you might get with normal output.
I suppose this was intenti
Tom Lane wrote:
> "depesz" <[EMAIL PROTECTED]> writes:
> > Description:csvlog skips some logs
>
> The point here is that CSV-format log output doesn't include the
> DETAIL, HINT, or context (QUERY/STATEMENT/CONTEXT) lines that
> you might get with normal output.
>
> I suppose this was int
"depesz" <[EMAIL PROTECTED]> writes:
> Description:csvlog skips some logs
The point here is that CSV-format log output doesn't include the
DETAIL, HINT, or context (QUERY/STATEMENT/CONTEXT) lines that
you might get with normal output.
I suppose this was intentional in order to keep the CS
The following bug has been logged online:
Bug reference: 3799
Logged by: depesz
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.3 HEAD
Operating system: linux, 32bit
Description:csvlog skips some logs
Details:
when settings are set to:
# select name, setting,
24 matches
Mail list logo
