On 07/30/2015 07:12 AM, Melvin Davidson wrote:
Thanks for the quick reply Adrian.
Further testing shows this can happen in other situations.
So:
aklaver@panda:~> psql -d test
psql (9.4.2)
Type "help" for help.
test=>
where trust is set up for local connections yields:
[unknown]-2015-07-30 07:25:36.614 PDT-0LOG: connection received:
host=[local]
aklaver-2015-07-30 07:25:36.615 PDT-0LOG: connection authorized:
user=aklaver database=test
So unknown is a placeholder until a username is found or not.
On Thu, Jul 30, 2015 at 10:09 AM, Adrian Klaver
<adrian.klaver@xxxxxxxxxxx <mailto:adrian.klaver@xxxxxxxxxxx>> wrote:
On 07/30/2015 06:42 AM, Melvin Davidson wrote:
> I have a puzzling question.
>
> All through the error log, there are connections for [unknown] user.
> EG:
> 2015-07-30 00:00:00 CDT [6577]: [1-1]: : [unknown]: LOG: connection
> received: host=173.239.101.98 <tel:173.239.101.98> port=50687
>
> The log_line_prefix is %t [%p]: [%l-1]: %h: %u:
>
> I can understand that the host is not available in nslookup, but why is
> the user not being recorded?
A quick look at the source shows that Postgres system process can
have NULL username:
postinit.c:
else if (IsBackgroundWorker)
{
if (username == NULL)
{
InitializeSessionUserIdStandalone();
am_superuser = true;
which is then turned into 'unknown'
elog.c:
case 'u':
if (MyProcPort)
{
const char *username = MyProcPort->user_name;
if (username == NULL || *username == '\0')
username = _("[unknown]");
>
> *Melvin Davidson*
--
Adrian Klaver
adrian.klaver@xxxxxxxxxxx <mailto:adrian.klaver@xxxxxxxxxxx>
--
*Melvin Davidson*
I reserve the right to fantasize. Whether or not you
wish to share my fantasy is entirely up to you.
--
Adrian Klaver
adrian.klaver@xxxxxxxxxxx
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general