Skip to content

Conversation

kim
Copy link
Contributor

@kim kim commented Sep 15, 2025

Description of Changes

Adds a way to configure the DbConnection to use confirmed reads.

Expected complexity level and risk

1

Testing

Still figuring out...

@kim kim marked this pull request as ready for review September 16, 2025 10:06
@kim kim requested review from jsdt and cloutiertyler September 16, 2025 10:06
@kim
Copy link
Contributor Author

kim commented Sep 16, 2025

I've been digging around for a way to test this, but it seems like additional URL parameters are added only on a "real" connection object, so it would require an e2e test harness.

If anyone has a better idea, please let me know.

Copy link
Contributor

@cloutiertyler cloutiertyler left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Very hyped for this! Just want to ask about confirmedReads vs synchronousCommit (i.e. the color of the bikeshed). I'm okay with either, but wanted to ask if it's worth considering the other for the purpose of being closer to Postgres. Presumably for PGWire it will be literally SET synchronous_commit = ON;

Copy link
Contributor

@jsdt jsdt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks straight-forward enough that I don't think we need to add automated testing in this PR. I would like to make the default be to not specify a value, rather than defaulting to false.

@kim
Copy link
Contributor Author

kim commented Sep 17, 2025

the color of the bikeshed

There is a subtle difference, in that Postgres allows to apply synchronous_commit to individual transactions, whereas we apply it to the entire connection.

That is, from the client's perspective, enabling confirmed reads will affect visibility of transactions made by others (note that this is different from the reducer's perspective).

So, re-using the terminology when it's not exactly the same semantics seems like it could cause confusion.
I'd be open to using "consistency level" or something, although that's arguably less concise and even more jargon-y.

@bfops bfops added the release-any To be landed in any release window label Sep 22, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
release-any To be landed in any release window
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants