Is your feature request related to a problem? Please describe.
We are introducing load shedding to our Postgres connection pooler and upon testing we have realized that Conn.BeginTx unconditionally calls c.die() on any error from the BEGIN statement (here), even if the error is a clean server‑side rejection (an ErrorResponse + ReadyForQuery, connection still usable), which causes it so under stress, connections on the pool are constantly destroyed and re-created, which puts even a bigger load on our connection pooler.
Describe the solution you'd like
Ideally, we should be able to define on the pgx config which error codes we consider non-fatal and not kill the connection upon receiving said errors. This way we don't churn connections to the connection pooler. Also possibly have a config to not kill the connection if the error code is not a fatal.
Describe alternatives you've considered
As of now, we have implemented our own custom Tx struct which basically checks the error code and avoids closing the connections at the begin if it is an insufficient resources error code (53000), which is the one we send if the connection pooler is rejecting queries due to load shedding.
Additional context
I believe other Postgres proxies like Multigres and PGKeeper implement or plan to implement load shedding capabilities, so this functionality wouldn't be scoped only to our case.
Is your feature request related to a problem? Please describe.
We are introducing load shedding to our Postgres connection pooler and upon testing we have realized that
Conn.BeginTxunconditionally callsc.die()on any error from the BEGIN statement (here), even if the error is a clean server‑side rejection (anErrorResponse+ReadyForQuery, connection still usable), which causes it so under stress, connections on the pool are constantly destroyed and re-created, which puts even a bigger load on our connection pooler.Describe the solution you'd like
Ideally, we should be able to define on the pgx config which error codes we consider non-fatal and not kill the connection upon receiving said errors. This way we don't churn connections to the connection pooler. Also possibly have a config to not kill the connection if the error code is not a fatal.
Describe alternatives you've considered
As of now, we have implemented our own custom
Txstruct which basically checks the error code and avoids closing the connections at the begin if it is an insufficient resources error code (53000), which is the one we send if the connection pooler is rejecting queries due to load shedding.Additional context
I believe other Postgres proxies like Multigres and PGKeeper implement or plan to implement load shedding capabilities, so this functionality wouldn't be scoped only to our case.