feat: extend passthrough auth to mirror destinations#1233
Open
lalvania wants to merge 1 commit into
Open
Conversation
When passthrough_auth adds a user record for the source database, also add the same user for every mirror destination whose source_db matches, so from_config's name-based source_users == dest_users check passes and the mirror pool is provisioned with the client-supplied password. Never overwrites an existing destination record — the operator may have deliberately configured per-side credentials. Only grace-fills entries whose password was left unset, matching the source-side add() behaviour. Adds integration/mirror/passthrough/ that plugs into the existing bare-metal mirror harness (integration/setup.sh provisions pgdog/pgdog1; run_pgdog picks up the subdir). Closes pgdogdev#1189
lalvania
force-pushed
the
feat/mirror-passthrough-auth
branch
from
July 18, 2026 02:19
e728b00 to
af2b47d
Compare
levkk
reviewed
Jul 18, 2026
| ); | ||
|
|
||
| { | ||
| let _lock = lock(); |
Collaborator
There was a problem hiding this comment.
I think you may want to take that lock a little earlier - when you get the config on line 232.
Codecov Report❌ Patch coverage is
📢 Thoughts on this report? Let us know! |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #1189 — Support Mirrors with pass through auth.
from_configonly provisions a mirror pool when the source and destination databases have matching[[users]]name sets. Passthrough only writes a[[users]]entry for the source side, so mirroring stays disabled. This patch also writes a matching entry for each mirror destination when passthrough runs, unlocking the name-match check. Any pre-existing destination entry is left alone.Rollout notes
For operators upgrading with a valid
users.toml:pgdog.tomlorusers.tomledits required.(name, database)already inusers.tomlwith a matching password is a zero-write, zero-reload no-op. Indistinguishable from pre-patch.(name, database)isn't inusers.toml. If you have no[[mirroring]]blocks it's dormant regardless.mirroring disabled ... users don't matchwarning should decrease (never increase) after upgrade. Increase = regression signal.enabled_allow_change, source-side rotation is unchanged. The mirror record is no longer rotated in lockstep — matters only if your mirror Postgres password is being rotated in sync with the source externally.Open questions
Three things worth calling out that I didn't want to decide unilaterally:
Should
[[mirroring]]only speak in[[databases]]? Should it care about user / authentication, or only that the source / target exists within[[databases]]? Or is this for establishing authentication?Should
[[users]]be server-side authentication only, while[[databases]]handles client-side auth only? Today[[users]]does both —name/passwordgate the client, and the same fields (orserver_*overrides) get used forpgdog → Postgres. A cleaner split might make this feature — and mirroring in general — less bolted-on.Should the ~1350-line inline
mod testsindatabases.rsbe extracted to a sibling file? The new tests join it in the same style. Thoughts on extracting this to a sibling crate like diesel'sdiesel_tests/?