river stuck connected to read-only postgres instance
维护者通常 1 天内回复
还没有人认领这个 Issue。
评估
- 难度
- 4/5
- 预计耗时
- 3-5 天
- 新手友好度
- 45/100
调研方向
Start by tracing River's leader connection and pgxpool error handling around the read-only transaction, recovery, and LISTEN failures described here. Compare that behavior with checking pg_is_in_recovery() or reconnecting through the cluster endpoint, and define done as safely recovering or stopping when the connection remains read-only; add focused coverage for the failover scenario if the existing test structure supports it.
由索引模型根据 Issue 内容生成。
描述
This scenario is admittedly operator error, but I am curious if there's anything River could do differently to self-heal.
We have a writer and reader in an AWS RDS cluster. Our service connects through a cluster endpoint which routes to the current writer. We needed to perform an OS patch so we upgraded the reader and then failed over so it became the writer. Then, we upgraded the former writer before failing back over to return to the original state. River's leader ended up pegged to the reader and could not do anything so we restarted the service to force a new connection which fixed the issue. The root cause is that a pgxpool connection obtained from the cluster endpoint is trusted as a writer for its entire lifetime, but Aurora flips roles without closing sockets.
Some of the errors we saw:
ERROR: cannot execute UPDATE in a read-only transaction (SQLSTATE 25006)
ERROR: cannot execute INSERT in a read-only transaction (SQLSTATE 25006)
error listening on topic "river_control": ERROR: cannot execute LISTEN during recovery (SQLSTATE 25006)
error scheduling jobs: ERROR: cannot execute SELECT FOR UPDATE in a read-only transaction (SQLSTATE 25006)
error cleaning jobs: ERROR: cannot execute DELETE in a read-only transaction (SQLSTATE 25006)
ERROR: cannot access temporary or unlogged relations during recovery (SQLSTATE 0A000)
If River could realize it's incorrectly connected to a read-only instance by inspecting errors or running something like pg_is_in_recovery(), it could attempt to reconnect and ultimately stop if it won't be successful. Again, I realize this is somewhat specific to our scenario ✌🏼
- 主要语言
- Go
- 星标
- 5.7k
- 派生
- 187
- 平均合并
- 1 天 11 小时
- 30 天内合并 PR
- 63
环境准备
这个项目没有提供开发容器、Dockerfile 或贡献指南，环境需要你自己搭建：先看它的 README，通用步骤见我们的新手贡献指南。
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
riverqueue/river 的其他 Issue
-
难度 2/5 1-3 小时 新手友好度 72/100
riverqueue/river#1454 · 1 条评论 ·
维护者通常 1 天内回复
-
AddWorkerSafely leaves registered kinds after an alias collision可能已有人在做 @flcrom 于 4 天前认领。 未关闭
难度 2/5 1-3 小时 新手友好度 25/100
riverqueue/river#1433 ·
维护者通常 1 天内回复
-
难度 4/5 3-5 天 新手友好度 52/100
riverqueue/river#1411 · 1 条评论 ·
维护者通常 1 天内回复
-
Remote JobCancel() can be silently lost while the notifier is reconnecting (no durable-poll fallback)可能已有人在做 关联的 PR 仍在进行中或已合并。 未关闭
难度 5/5 一周以上 新手友好度 45/100
riverqueue/river#1358 · 1 条评论 ·
维护者通常 1 天内回复
-
难度 4/5 3-5 天 新手友好度 35/100
riverqueue/river#1258 · 7 条评论 ·
维护者通常 1 天内回复
相似的 Issue
-
难度 2/5 1-3 小时 新手友好度 78/100
openimsdk/openim-sdk-core#1127 ·
-
github_actions
难度 2/5 1-3 小时 新手友好度 65/100
Hochfrequenz/aibap.mcp#578 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 85/100
mvanhorn/cli-printing-press#4980 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 62/100
lenaxia/LLMSafeSpaces#1644 · 3 条评论 · 1 个 reaction ·
维护者通常 1 天内回复
-
automation code-quality cookie documentation improvement quick-win task-mining
难度 2/5 1-3 小时 新手友好度 65/100
维护者通常 1 天内回复