Elvis Pranskevichus
Elvis Pranskevichus
The error traceback you provided doesn't seem to be related to authentication. Looks like a network issue to me. What do server-side logs show?
Authentication method is decided by the server based on configuration, asyncpg only reacts to what the server is asking it to do. See `_parse_msg_authentication`.
> It doesn't seem it's handling the scram sha 256? You are looking at a fairly old version of asyncpg. Why 0.18.2?
A full scan, and the use of temporary files, are triggered by the `ORDER BY` clause in your query. The server has to perform a very expensive operation *before* it...
In theory, there should be no difference between a `NO SCROLL CURSOR WITHOUT HOLD` and the protocol-level Portal asyncpg uses, but in your case there seems to be a difference....
Hi @nhumrich. Sorry for the delay in reviewing this and thanks for working on this. To start, I have a few of notes on the approach: 1. I don't like...
> Term "hook" is used as an event handler, You are confusing hooks with, well, event handlers or callbacks. The term "[hook](https://en.wikipedia.org/wiki/Hooking)" is well established as a mechanism to enable...
There is a comprehensive effort to add type annotations in #577
0.16.0 has `Pool.expire_connections()` which you can call on the failover event. Would that fix your use case?
I'm somewhat reluctant to add such policies to the base pool, as everyone's requirements are different. I think making `Pool.get_new_connection()` public would allow implementing this policy in a subclass cleanly.