From: | Vijaykumar Jain <vijaykumarjain(dot)github(at)gmail(dot)com> |
---|---|
To: | Michael Lewis <mlewis(at)entrata(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Boboc Cristi <bobocc(at)yahoo(dot)com>, PostgreSQL General <pgsql-general(at)lists(dot)postgresql(dot)org>, pgsql-general-owner(at)lists(dot)postgresql(dot)org |
Subject: | Re: Debugging features needed |
Date: | 2021-11-05 16:15:41 |
Message-ID: | CAM+6J94=6_FiqE=8GJQiN-0g3EM-1OaKve5S5MRu8RTugLpXjg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Fri, Nov 5, 2021, 7:46 PM Michael Lewis <mlewis(at)entrata(dot)com> wrote:
> For my purposes, app name isn't long enough so we put a comment at the
> start of every SQL that has a unique ID generated in the application. This
> ensures that we can tell one connection apart from another even when both
> are coming from the same feature/action (applicationName is set to this)
> even using connection pooling. Before, we had different requests reusing
> the same pid of course and if they happened to have the same appName, we
> didn't know it was a new process on app side.
>
While researching options, I did see crunchy proxy using annotations to
split read/write. But I was not sure if any of these options fit well with
multiple toolings , drivers etc.
The other option was
https://github.com/wgliang/pgproxy
or writing your custom plug-in for envoyproxy filter for postgresql
https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/other_protocols/postgres
So basically it was adding one more layer in between the already connection
pooling layers via pgbouncer.
The biggest concern is when we use ssl, these session params cannot be read
unless we terminate ssl at the proxy, and then decode, so I gave up :)
From | Date | Subject | |
---|---|---|---|
Next Message | Boboc Cristi | 2021-11-05 17:06:20 | Re: Debugging features needed |
Previous Message | Michael Lewis | 2021-11-05 14:16:09 | Re: Debugging features needed |