MagicStack / MagicStack/asyncpg

Intermittent no pg_hba.conf entry for host

未关闭
#1,241 3 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

还没有人认领这个 Issue。

主要语言
Python
星标
8.1k
派生
468
PR 合并指标
30 天内没有已合并 PR

描述

I have a long-running script which initializes an asyncpg.Pool at the start of the script, then spawns a ton of tasks on an eventloop which occasionally acquire a connection, write something and put the connection back. An individual connection could in theory go a long time between usages, since the writes are only occasional. Plenty of time for some of them to idle out. That may be relevant here, because exactly every ten minutes, I get a few errors like this in my task log:

`asyncpg.exceptions.InvalidAuthorizationSpecificationError: no pg_hba.conf entry for host`

The script goes through its recovery logic, throwing away of bunch of work that the task already did, and the script resumes working again. The connections continue working again for another 10 minutes - plenty of writes get through, so this is not really an auth error - then the cycle repeats.

This feels like asyncpg acquires a connection which is invalidated in some way, then raises when it checks the connection but before passing it along. I am not sure why the connections are invalidated, but the extreme regularity of it implies that the connections failed a keepalive or idled out and asyncpg doesn't account for the possibility in the acquire logic. It's also very possible that I have initialized the pool incorrectly and I'm seeing expected behavior. My pool's connection settings are all default. The connection is directly to PG, no middleware.

PostgreSQL 15.10 on x86_64-pc-linux-gnu, compiled by gcc (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0, 64-bit
asyncpg 0.30.0

Here is what I believe is the relevant part of the stack trace. All stack frames above this are my own code and the exception is thrown on a `async with pool.acquire() as conn:` line.

Am I running into expected behavior?

```
File "/home/redacted/miniconda3/envs/redacted/lib/python3.12/site-packages/asyncpg/pool.py", line 864, in _acquire
return await _acquire_impl()
^^^^^^^^^^^^^^^^^^^^^
File "/home/redacted/miniconda3/envs/redacted/lib/python3.12/site-packages/asyncpg/pool.py", line 849, in _acquire_impl
proxy = await ch.acquire() # type: PoolConnectionProxy
^^^^^^^^^^^^^^^^^^
File "/home/redacted/miniconda3/envs/redacted/lib/python3.12/site-packages/asyncpg/pool.py", line 140, in acquire
await self.connect()
File "/home/redacted/miniconda3/envs/redacted/lib/python3.12/site-packages/asyncpg/pool.py", line 132, in connect
self._con = await self._pool._get_new_connection()
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/redacted/miniconda3/envs/redacted/lib/python3.12/site-packages/asyncpg/pool.py", line 517, in _get_new_connection
con = await self._connect(
^^^^^^^^^^^^^^^^^^^^
File "/home/redacted/miniconda3/envs/redacted/lib/python3.12/site-packages/asyncpg/connection.py", line 2421, in connect
return await connect_utils._connect(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/redacted/miniconda3/envs/redacted/lib/python3.12/site-packages/asyncpg/connect_utils.py", line 1049, in _connect
conn = await _connect_addr(
^^^^^^^^^^^^^^^^^^^^
File "/home/redacted/miniconda3/envs/redacted/lib/python3.12/site-packages/asyncpg/connect_utils.py", line 891, in _connect_addr
return await __connect_addr(params_retry, False, *args)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/redacted/miniconda3/envs/redacted/lib/python3.12/site-packages/asyncpg/connect_utils.py", line 934, in __connect_addr
await connected
```

贡献指南

这个仓库没有索引到贡献指南

从这里开始

  1. 先读完整个 Issue,再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库,在一个分支上完成修改。
  4. 提交 Pull Request,并在描述里引用这个 Issue 编号。

调研方向

从 asyncpg/pool.py 中的 _acquire、PoolConnectionHolder.acquire 和 _get_new_connection 开始,然后根据提供的 stack trace 跟踪 asyncpg/connect_utils.py,直到 __connect_addr。使用 PostgreSQL 15.10 和 asyncpg 0.30.0 重现反复出现的故障,并确定 pool acquisition 是否按预期处理报告的连接错误;如果适用,应通过 regression test 明确确定其行为及任何必要的变更,才算完成。

由索引模型根据 Issue 内容生成。

评估

技术栈
postgresql, python
领域
databases
Issue 类型
缺陷
难度
4/5
预计耗时
3-5 天
活跃度
停滞
描述清晰度
需要澄清
新手友好度
25/100

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。