river stuck connected to read-only postgres instance

Open
#1,225 14 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
45/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Quiet
Tech stack
aws, go, postgresql

Research direction

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.

Written by the indexing model from the issue text.

Description

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 ✌🏼

Dominant language
Go
Stars
5.9k
Forks
197
Avg merge
1d 4h
Merged PRs (30d)
120

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from riverqueue/river

All issues in riverqueue/river

Similar issues

More Go issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.