This function can panic due to slicing out of bounds when the server
responds without the `\x` prefix. With this commit we instead error and
also ensure that the prefix is what we expect instead of blindly
removing it.
Not directly related to the panic, we replace as_str() with as_bytes()
because there is no reason to perform a utf8 validity check when
hex::decode already checks that the content is valid.
* Fixed leak of `Arc<SharedPool>` in `DecrementSizeGuard::cancel()`
* Renamed `PoolOptions::connect_timeout` to `acquire_timeout` for clarity.
* Fixed `/* SQLx ping */` showing up in Postgres query logs
* Made `.close()` a regular function that returns a `Future`
* Deleted deprecated method `PoolConnection::release()`
* Document why connection might be dropped if `Pool::acquire()` is cancelled
* Added connection metadata to pool lifecycle callbacks
* Improved guarantees for `min_connections`
* Fixed `num_idle()` to not spin forever at high load
* Improved documentation across the `pool` module
Postgres arrays and records do not fully support custom types. When encountering an unknown OID, they currently default to using `PgTypeInfo::with_oid`. This is invalid as it breaks the invariant that decoding only uses resolved types, leading to panics.
This commit returns an error instead of panicking. This is merely a mitigation: a proper fix would actually add full support for custom Postgres types. Full support involves more work, so it may still be useful to fix this immediate issue.
Related issues:
- https://github.com/launchbadge/sqlx/issues/1672
- https://github.com/launchbadge/sqlx/issues/1797
* postgres: use Oid type instead of u32
* Make serde happy
* Expose the inner u32
* docs
* Try to fix tests
* Fix unit tests
* Fix order
* Not sure what happened here
This commit fixes the array decoder to support custom types. The core of the issue was that the array decoder did not use the type info retrieved from the database. It means that it only supported native types.
This commit fixes the issue by using the element type info fetched from the database. A new internal helper method is added to the `PgType` struct: it returns the type info for the inner array element, if available.
Closes#1477
* fix: wait until ready after executing other helper queries while pg quering is executing
Signed-off-by: Atkins Chang <atkinschang@gmail.com>
* fix: use tls parameter for testing target
Signed-off-by: Atkins Chang <atkinschang@gmail.com>
* a task that is marked woken but didn't actually wake before being cancelled will instead wake the next task in the queue
* a task that wakes but doesn't get a connection will put itself back in the queue instead of waiting until it times out with no way to be woken
* the idle reaper now won't run if there are tasks waiting for a connection, and also uses
the proper `SharedPool::release()` to return validated connections to the pool so waiting tasks get woken
closes#622, #1210
(hopefully for good this time)
Signed-off-by: Austin Bonander <austin@launchbadge.com>
* fix `DecrementSizeGuard::drop()` only waking one `Waiter` regardless of whether that waiter was already woken
* fix connect-backoff loop giving up the size guard
* don't cut in line to open a new connection
* have tasks waiting on `acquire()` wake periodically to check if there's a connection in the queue
Signed-off-by: Austin Bonander <austin@launchbadge.com>
Fix commit updates the `postgres::connection::describe` module to add full support for domain types. Domain types were previously confused with their category which caused invalid oid resolution.
Fixeslaunchbadge/sqlx#110
BREAKING CHANGE: some columns in `query!()` et. al. output will change from `T` to `Option<T>`
breakage should be minimal in practice as
these columns will need to have been manually
overridden anyway to avoid runtime errors
Signed-off-by: Austin Bonander <austin@launchbadge.com>
This solves a problem when needing to describe a query before executing
it, in cases where the query is more of a dynamic nature and binding its
parameters require the type info.
In this case, the first describe doesn't know the input parameters, so
the parameter type info is inferred from the database. In cases of
`varchar(10)[]` or `json` column types, the parameter type is inferred
to the column type. Now if we then try to use `text[]` or `jsonb` as the
types, the database has already stored different types for these
parameters for the statement, and will error out.
So we'll now only store the statement to the cache when it comes from an
actual execution of the query.
