On Fri., 20 Apr. 2018, 06:59 Andres Freund, <and...@anarazel.de> wrote:
> On 2018-04-19 15:01:24 -0400, Tom Lane wrote: > > Only after you can say "there's nothing wrong with this that isn't > > directly connected to its not being in-core" does it make sense to try > > to push the logic into core. > > I think there's plenty things that don't really make sense solving > outside of postgres: > - additional added hop / context switches due to external pooler > - temporary tables > - prepared statements > - GUCs and other session state > Totally agreed. Poolers can make some limited efforts there, but that's all. Poolers also have a hard time determining if a query is read-only or read/write. Wheas Pg its self has a better chance, and we could help it along with function READONLY attributes if we wanted. This matters master/standby query routing. Standbys being able to proxy for the master would be fantastic but isn't practical without some kind of pooler. > I think there's at least one thing that we should attempt to make > easier for external pooler: > - proxy authorization > Yes, very yes. I've raised this before in a limited form - SET SESSION AURHORIZATION that cannot be reset without a cookie value. But true proxy auth would be better.
