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
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)
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
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 <[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
