On Wed, Jan 20, 2021 at 3:53 PM James Coleman wrote:
>
> On Wed, Jan 20, 2021 at 9:58 AM Simon Riggs wrote:
> >
> > On Wed, 20 Jan 2021 at 14:21, James Coleman wrote:
> >
> > > An alternative approach that occurred to me while typing this reply: a
> > > setting in Postgres that would disallow se
On Wed, Jan 20, 2021 at 9:58 AM Simon Riggs wrote:
>
> On Wed, 20 Jan 2021 at 14:21, James Coleman wrote:
>
> > An alternative approach that occurred to me while typing this reply: a
> > setting in Postgres that would disallow setting session level GUCs
> > (i.e., enforce `SET LOCAL` transaction
On Wed, 20 Jan 2021 at 14:21, James Coleman wrote:
> An alternative approach that occurred to me while typing this reply: a
> setting in Postgres that would disallow setting session level GUCs
> (i.e., enforce `SET LOCAL` transaction level usage instead) would
> remove a large chunk of our need t
I hope to do further review of the patch later this week, but I wanted
to at least comment on this piece:
On Wed, Jan 20, 2021 at 2:48 AM Peter Eisentraut
wrote:
>
> On 2020-12-23 15:33, Simon Riggs wrote:
> > Poolers such as pgbouncer would then be able to connect transaction
> > mode pools by s
On 2020-12-23 15:33, Simon Riggs wrote:
Poolers such as pgbouncer would then be able to connect transaction
mode pools by setting transaction_cleanup=on at time of connection,
avoiding any need to issue a server_reset_query, removing the DISCARD
ALL command from the normal execution path, while s
On 12/23/20 6:49 PM, Simon Riggs wrote:
The whole premise of the patch is tighter integration, with the server
providing the facilities that poolers need.
I am all for that. Ideally I would want builtin connection pooling but
short term I think the way forward is most likely tighter integratio
On Wed, 23 Dec 2020 at 15:19, Andreas Karlsson wrote:
>
> On 12/23/20 3:47 PM, Vladimir Sitnikov wrote:
> > Simon>It seems strange to me that we put this work onto the pooler, forcing
> > Simon>poolers to repeatedly issue the same command
> >
> > What if poolers learn to manage connections and pre
On 12/23/20 3:47 PM, Vladimir Sitnikov wrote:
Simon>It seems strange to me that we put this work onto the pooler, forcing
Simon>poolers to repeatedly issue the same command
What if poolers learn to manage connections and prepared statements better?
Then poolers won't have to reset the session ev
Simon>It seems strange to me that we put this work onto the pooler, forcing
Simon>poolers to repeatedly issue the same command
What if poolers learn to manage connections and prepared statements better?
Then poolers won't have to reset the session every time, and everyone wins.
Simon>This has an
