Re: Invalid length of startup packet

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Nigel J(dot) Andrews" <nandrews(at)investsystems(dot)co(dot)uk>
Cc: Ron Snyder <snyder(at)roguewave(dot)com>, "'Henrik Steffen'" <steffen(at)city-map(dot)de>, pgsql-general(at)postgresql(dot)org
Subject: Re: Invalid length of startup packet
Date: 2002-05-28 14:58:58
Message-ID: 3116.1022597938@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

"Nigel J. Andrews" <nandrews(at)investsystems(dot)co(dot)uk> writes:
> Obviously, that's not entirely usable if connections are being made
> and dropped by applications. So how about elog() sticking the backend
> slot number into all messages? Is that sort of information available
> in elog?

No; in fact there is no backend slot number assigned yet during startup
processing. But elog already can record the process PID, and that's
probably what you'd want to use to correlate these messages. I'm
envisioning log entries like

timestamp [PID] LOG: received connection from foo.bar port 12345
timestamp [PID] FATAL: Invalid length of startup packet

The PID in the first of these messages would already be the PID of the
forked-off child, so there would be a clear correlation to the following
failure message, even if other connection requests were being processed
at about the same time.

regards, tom lane

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Chris Humphries 2002-05-28 15:01:02 triggers cant see functions
Previous Message Andrew Sullivan 2002-05-28 14:53:46 Re: [HACKERS] Re : Solaris Performance - 64 bit puzzle