When a batch successfully prepared some statements, but then failed to
prepare others, the prepared statements that were successfully prepared
were not properly cleaned up. This could lead to a "prepared statement
already exists" error on subsequent attempts to prepare the same
statement.
https://github.com/jackc/pgx/issues/1847#issuecomment-2347858887
When loading even a single type into pgx's type map, multiple SQL
queries are performed in series. Over a slow link, this is not ideal.
Worse, if multiple types are being registered, this is repeated multiple
times.
This commit add LoadTypes, which can retrieve type
mapping information for multiple types in a single SQL call, including
recursive fetching of dependent types.
RegisterTypes performs the second stage of this operation.
When a conn is going to execute a query, the first thing it does is to
deallocate any invalidated prepared statements from the statement cache.
However, the statements were removed from the cache regardless of
whether the deallocation succeeded. This would cause subsequent calls of
the same SQL to fail with "prepared statement already exists" error.
This problem is easy to trigger by running a query with a context that
is already canceled.
This commit changes the deallocate invalidated cached statements logic
so that the statements are only removed from the cache if the
deallocation was successful on the server.
https://github.com/jackc/pgx/issues/1847
The only way to change the query mode used by Batch.Queue and
SendBatch is to use a connection with a different
DefaultQueryExecMode. Add this to the function documentation.
Conn.SendBatch: Move where mode is defined to make this clearer in
the code. I spent time looking for the option that does not exist.
This uses the PostgreSQL protocol to deallocate a prepared statement
instead of a SQL statement. This allows it to work even in an aborted
transaction.
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.
If the default_query_exec_mode is unknown, the returned error
previously was:
invalid default_query_exec_mode: <nil>
This changes it to return the argument. Add a test that unknown modes
fail to parse and include this string.
Previously, items were never removed from the preparedStatements map.
This means workloads that send a large number of unique queries could
run out of memory. Delete items from the map when sending the
deallocate command to Postgres. Add a test to verify this works.
Fixes https://github.com/jackc/pgx/issues/1456
Table types have system / hidden columns like tableoid, cmax, xmax, etc.
These are not included when sending or receiving composite types.
https://github.com/jackc/pgx/issues/1576
CopyFrom had to create a prepared statement to get the OIDs of the data
types that were going to be copied into the table. Every COPY operation
required an extra round trips to retrieve the type information. There
was no way to customize this behavior.
By leveraging the QueryExecMode feature, like in `Conn.Query`, users can
specify if they want to cache the prepared statements, execute
them on every request (like the old behavior), or bypass the prepared
statement relying on the pgtype.Map to get the type information.
The `QueryExecMode` behave exactly like in `Conn.Query` in the way the
data type OIDs are fetched, meaning that:
- `QueryExecModeCacheStatement`: caches the statement.
- `QueryExecModeCacheDescribe`: caches the statement and assumes they do
not change.
- `QueryExecModeDescribeExec`: gets the statement description on every
execution. This is like to the old behavior of `CopyFrom`.
- `QueryExecModeExec` and `QueryExecModeSimpleProtocol`: maintain the
same behavior as before, which is the same as `QueryExecModeDescribeExec`.
It will keep getting the statement description on every execution
The `QueryExecMode` can only be set via
`ConnConfig.DefaultQueryExecMode`, unlike `Conn.Query` there's no
support for specifying the `QueryExecMode` via optional arguments
in the function signature.
Jack Christensen
martinpasaribu
merlin
Nick Farrell
Oleksandr Redko
Pavlo Golub
James Hartig
Evan Jones
Simon Paredes
Ville Skyttä
Julien GOTTELAND
Alexey Palazhchenko
Felix Röhrich
Alejandro Do Nascimento Mora
Yevgeny Pats
Vitalii Solodilov
Bodo Kaiser