Handle auth_query correctly for replication connections#1166
Conversation
51180fe to
8cacb6a
Compare
|
Hi, how is it going? just wanted to check if there was any progress here as this is still not working as expected. Thanks! |
The way we send an auth_query is a bit strange. We temporarily set the pool of the client to the pool for the auth_user, and then continue connection startup like normal. This broke for replication connections because we would send the replication parameter for that connection too. This fixes that by only doing special connection setup thing for replication connections if we're not currently trying to send an auth_query. Fixes pgbouncer#1164
eulerto
left a comment
There was a problem hiding this comment.
For some reason, the test_physical_rep_pg_basebackup is failing for me. There is no explicit errors in the log (Postgres and PgBouncer).
==================================================== short test summary info =====================================================
FAILED test/test_replication.py::test_physical_rep_pg_basebackup - Failed: Timeout >30.0s
=============================== 1 failed, 210 passed, 7 skipped, 13 warnings in 138.12s (0:02:18) ================================
make: *** [Makefile:162: check] Error 1
Is this only with this PR, or also on master? I cannot reproduce it, and CI is running fine too. So I'm leaning towards merging this unless this is only happening on this PR for you. Regarding debugging, did you uncomment the following line during the test? That should give much more info into what's happening. |
|
FWIW, this issue was blocking us (because it turns out HUP'ing pgBouncer also resets connections which were made with credentials found in auth_file, and resetting logical replication connections on a regular basis is not great), but applying this patch seems to work well in our testing. With this patch, we can now successfully establish and maintain a logical replication session authenticated with auth_query, even while we HUP pgBouncer every few minutes. |
|
Hi @JelteF Thanks again for the great work and support! |
The way we send an auth_query is a bit strange. We temporarily set the pool of the client to the pool for the auth_user, and then continue connection startup like normal. This broke for replication connections because we would send the replication parameter for that connection too. This fixes that by only doing our special connection setup logic for replication connections if we're not currently trying to send an auth_query. Fixes pgbouncer#1164
The way we send an auth_query is a bit strange. We temporarily set the
pool of the client to the pool for the auth_user, and then continue
connection startup like normal. This broke for replication connections
because we would send the replication parameter for that connection too.
This fixes that by only doing our special connection setup logic for
replication connections if we're not currently trying to send an
auth_query.
Fixes #1164