On Thu, Jun 15, 2017 at 3:11 AM, Satyanarayana Narlapuram <satyanarayana.narlapu...@microsoft.com> wrote: > 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.
Wire protocol changes are scary, because they can result in a need to update every client connector and every bit of middleware that speaks PostgreSQL, not just the server. If we thought this feature had enough value to justify adding it, we could add it as an optional feature so that existing clients don't break. But if we added it and only libpq and the server ended up supporting it, that would be a disappointing outcome. > 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). Are you imagining that this would be done by the client or by the driver the client is using? If the latter, it's transparent but maybe useless, because the client won't even know that this ID got created. If it's done by the client code proper, then it only works if not only the server and every bit of middleware and every connector but also every client application in the world is updated, which does not seem like a thing that is likely to occur. > This field can be an optional field driven by the connection parameters for > PSql (-C or--include-clientId). This makes it sound like you're imagining it being added by an explicit action on the part of the client, which means we're in update-every-PostgreSQL-application-in-the-world territory. > P.S: I am looking for initial feedback on this idea and can provide more > design details if needed. I think you need to build a more compelling case for why this would be useful, why application_name isn't the right answer, and how we avoid forcing everybody in the world to worry about this new thing. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers