Re: Adding connection id in the startup message

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Satyanarayana Narlapuram <Satyanarayana(dot)Narlapuram(at)microsoft(dot)com>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Adding connection id in the startup message
Date: 2017-06-15 13:50:17
Message-ID: 30267.1497534617@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Satyanarayana Narlapuram <Satyanarayana(dot)Narlapuram(at)microsoft(dot)com> writes:
> As a cloud service, Azure Database for PostgreSQL uses a gateway proxy to route connections to a node hosting the actual server. Potentially there could be multiple hops (for example client, optional proxy at the client like pgbouncer for connection pooling, Azure gateway proxy, backend server) in between the client, and the server. For various reasons (client firewall rules, network issues etc.), the connection can be dropped before it is fully authenticated at one of these hops, and it becomes extremely difficult to say where and why the connection is dropped.
> The proposal is to tweak the connectivity wire protocol, and add a connection id (GUID) filed in the startup message. We can trace the connection using this GUID and investigate further on where the connection failed.
> Client adds a connection id in the startup message and send it to the server it is trying to connect to. Proxy logs the connection id information in its logs, and passes it to the server. Server logs the connection Id in the server log, and set it in the GUC variable (ConnectionId).

> When an attempt to connection to the server fails, the connection failed message must include the connection id in the message. This Id can be used to trace the connection end to end.
> Customers can provide this Id to the support team to investigate the connectivity issues to the server, along with the server information.

This seems like a lot of added mechanism for not very much gain.
In particular, it wouldn't help at all unless the client side were
also on board with generating a connection UUID and making it visible
to the end user, and then you'd have to get proxy authors on board,
etc etc, so you have to sell the idea to a lot more people than just the
server hackers. Can you give a concrete example where this would have
helped above and beyond knowing, eg, the source and time of the connection
attempt?

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2017-06-15 13:52:27 Re: Refreshing subscription relation state inside a transaction block
Previous Message Peter Eisentraut 2017-06-15 13:45:51 Re: Typo in comment in ecpg datetime.c