This error was introduced by 0f0d236599.
If the same statement was prepared multiple times then whenever Close
was called on one of the statements the underlying prepared statement
would be closed even if other statements were still using it.
https://github.com/jackc/pgx/issues/1754#issuecomment-1752004634
stdlib now uses the functionality introduced in
bbe2653bc5 for prepared statements. This
means that the prepared statement name is stable for a given query even
across connections and program executions.
It also makes tracing easier.
See https://github.com/jackc/pgx/issues/1754
QueryExecModeCacheDescribe actually is safe even when the schema or
search_path is modified. It may return an error on the first execution
but it should never silently encode or decode a value incorrectly. Add a
test to demonstrate and ensure this behavior.
Update documentation of QueryExecModeCacheDescribe to remove warning of
undetected result decoding errors.
Update documentation of QueryExecModeCacheStatement and
QueryExecModeCacheDescribe to indicate that the first execution of an
invalidated statement may fail.
The Rows interface in pgx, like its ancestor in database/sql, is easy to
accidentally misuse in a way that can cause apps to misinterpret
database or connection errors as successful queries with empty or
truncated result-sets.
Update the docs to emphasise the need to call rows.Err() after
rows.Next() returns false, and direct users of the interface to the v5
API helpers that make writing correct code easier.
The docs on Conn.Query() already call this out, so only a small change
is needed to warn users and point them at the details on Query()
Per details in #1707
Previously it was checking TotalConns but that includes ConstructingConns.
Instead it should directly check IdleConns so the next Acquire takes one of
those and doesn't make a 3rd connection. The check against the context was
also wrong which prevented this from timing out after 2 minutes.
This also fixes a bug where NewConnsCount was not correctly counting
connections created by Acquire directly.
Fixes#1690
It was previously possible for a connection to be created while the
background health check was running. The health check could create
connection(s) in excess of the maximum pool size in this case.
https://github.com/jackc/pgx/issues/1660
connect_timeout given in conn string was not obeyed if sslmode is not specified (default is prefer) or equals sslmode=allow|prefer. It took twice the amount of time specified by connect_timeout in conn string. While this behavior is correct if multi-host is provided in conn string, it doesn't look correct in case of single host. This behavior was also not matching with libpq.
The root cause was to implement sslmode=allow|prefer conn are tried twice. First with TLSConfig and if that doesn't work then without TLSConfig. The fix for this issue now uses the same context if same host is being tried out. This change won't affect the existing multi-host behavior.
This PR goal is to close issue [jackc/pgx/issues/1672](https://github.com/jackc/pgx/issues/1672)
Jack Christensen
Nicola Murino
Ville Skyttä
Vincent Le Goff
Mochammad Hanif R
Lev Zakharov
Julien GOTTELAND
Craig Ringer
Alexey Palazhchenko
horpto
James Hartig
Rafi Shamim
Evan Jones
smaher-edb
Christoph Engelbert (noctarius)