New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Investigate alternatives to required PgBouncer configuration #2453
Comments
An idea re suggestion 3: This might possibly be able to be verified via pure queries against a normal Postgres server:
If this works, we "just" need to find a way to express that in our code. |
3 is less queries, but then in case of an error, that failing query needs to:
This means a non-deterministic spike on response times that's random. In the failing case, if the original transaction was three queries, the procedure runs the three queries + |
A quick test shows this is possible: use postgres::{Client, NoTls};
fn main() {
let mut client =
Client::connect("host=localhost user=postgres password=prisma", NoTls).unwrap();
let mut tx = client.transaction().unwrap();
tx.execute("DEALLOCATE ALL", &[]).unwrap();
for row in tx.query("SELECT 1 as integer", &[]).unwrap() {
dbg!(row);
}
tx.commit().unwrap();
} So the plan would be to introduce in Postgres connector in Quaint a new builder option Then QE would turn this bit on if needed. |
I verified suggestion 3 on a SQL level as well:
So if we catch error The table |
Investigation concluded: Suggestion 3 would probably work as well, but is a bit hard to put into the architecture we have. Suggestion 2 is a more blunt hammer but seems to work as a replacement for the custom configuration of PgBouncer. |
We recently became aware that DO's and Heroku's PgBouncer do not allow configuration as we advise, making it impossible for Prisma users to use them in front of their Postgres databases.
In an internal document we researched and documented the problem and its causes that make it necessary to have these 2 configuration options to use PgBouncer. Additionally I came up with 4 suggestion on how we could avoid having to use these configuration options, making it possible for our users to user PgBouncer of DO and Heroku.
After internal discussion we want to look into suggestions 2 and 3 deeper:
Clean up manually before/after each transaction
a) We could send
DEALLOCATE ALL
manually after each transaction (faking what the PgBouncer configuration would do automatically).b) We could send
DEALLOCATE ALL
manually before each transaction (making sure we have a clean slate before trying to prepare the query).Clean up manually if clash was detected
We could catch the
prepared statement "s2" already exists
error when trying to prepare a query, manually send aDEALLOCATE ALL
(or evenDEALLOCATE s2
) query, and then try to prepare the query again.We are not super sure if these suggestion actually work (2a could be problematic if we can actually send the query before we lose our connection by committing a transaction, 3 could be problematic with losing the transaction (and thus connection) on the error).
Hence we need to investigate.
Comments:
If possible we prefer 3 over 2 as it affects less queries.
If 3 is not possible, 2a more mirrors the PgBouncer behavior, but 2b might be easier to achieve.
The text was updated successfully, but these errors were encountered: