dependabot[bot] [Wed, 1 Oct 2025 07:12:45 +0000 (07:12 +0000)]
chore(deps): bump the actions group across 1 directory with 4 updates
Bumps the actions group with 4 updates in the / directory: [actions/checkout](https://github.com/actions/checkout), [actions/setup-python](https://github.com/actions/setup-python), [pypa/cibuildwheel](https://github.com/pypa/cibuildwheel) and [actions/github-script](https://github.com/actions/github-script).
Updates `actions/checkout` from 4 to 5
- [Release notes](https://github.com/actions/checkout/releases)
- [Changelog](https://github.com/actions/checkout/blob/main/CHANGELOG.md)
- [Commits](https://github.com/actions/checkout/compare/v4...v5)
Updates `actions/setup-python` from 5 to 6
- [Release notes](https://github.com/actions/setup-python/releases)
- [Commits](https://github.com/actions/setup-python/compare/v5...v6)
Updates `pypa/cibuildwheel` from 3.1.4 to 3.2.0
- [Release notes](https://github.com/pypa/cibuildwheel/releases)
- [Changelog](https://github.com/pypa/cibuildwheel/blob/main/docs/changelog.md)
- [Commits](https://github.com/pypa/cibuildwheel/compare/v3.1.4...v3.2.0)
Updates `actions/github-script` from 7 to 8
- [Release notes](https://github.com/actions/github-script/releases)
- [Commits](https://github.com/actions/github-script/compare/v7...v8)
The server version reported is 250300. Tests fail with the error:
psycopg.errors.OperatorIntervention: this schema change is
disallowed because table "execmany" is locked and this operation cannot
automatically unlock the table
DETAIL: To unlock the table, execute `ALTER TABLE execmany SET (schema_locked = false);`
After the schema change completes, we recommend setting it back to
true with `ALTER TABLE execmany SET (schema_locked = true);`.
HINT: Locking the table improves changefeed performance; see
https://www.cockroachlabs.com/docs/dev/changefeed-best-practices.html#lock-the-schema-on-changefeed-watched-tables
fix: drop warning for objects passed as JSON lods/dump function
Just optimistically assume that they are ok and will not cause leaks.
The possibility of there being something else which might cause a leak
is lower than the possibility that we didn't think about something else
and raise a warning, refusing to cache the loader, and really cause a
leak.
Daniele Varrazzo [Wed, 14 May 2025 15:16:03 +0000 (17:16 +0200)]
fix: collect notifies only if no handler was registered
If someone is listening to notifications by using an handler, the
notifies backlog would fill without ever being emptied.
This change has the risk of breaking something if someone is relying on
notifies being received both via callback and via generator, but I don't
know how to satisfy it without creating a leak to users who don't use the
generator. Will ask around...
fix: keep a lock for the entire duration of executemany
Before this change we had the lock context inside the pipeline context,
because conn.pipepline() and Pipeline.__enter/exit__ take a lock. But
this created windows of opportunities for other threads to execute
concurrent operations on the connection, resulting in "another command
is already in progress" errors.
Daniele Varrazzo [Fri, 29 Aug 2025 15:11:54 +0000 (17:11 +0200)]
ci(alpine): install missing libraris required to test and package wheels
Since some recent alpine version the krb5-libs package is not installed by
default anymore. When building the libpq the package got installed as a
side effect of installing krb5-dev, but, in case libpq build was cached,
the libraries would have been missing when packaging the wheel or
importing psycopg for test.
Daniele Varrazzo [Mon, 25 Aug 2025 16:35:30 +0000 (18:35 +0200)]
feat: add support for libpq PQconnectionUsedGSSAPI()
We will not advertise its presence as PGconn.used_gssapi until Psycopg
3.3. However we can use it internally to implement a warning to check
the implicit usage of gssencmode=prefer.
Create all the connections beforehand otherwise some may reuse the same
address, resulting in a duplicated warning message, which would be
omitted and fail the test.
fix: don't call str(self) or imported objects in __del__
We easily end up trying to access resources already unavailable in the
objects representation. In Python 3.14 this seems to happen aggressively
(or maybe it's just more visible because testing a dev version).
Daniele Varrazzo [Tue, 20 May 2025 15:06:06 +0000 (17:06 +0200)]
fix: change signature of SQL.join() to allow a sequence of Any
We declared accepting a sequence of Composable, but, because we passed
the joined values to `Composite`, actually non-composable were
interpreted as `Literal`.
Make this behaviour explicit by testing it and fixing the signature.
fix(json): don't leak when lambdas are used as dumps/loads function
Cache functions on the code, not on the function identity itself:
different lambdas or local functions are different objects but he
underlying code object is the same.
Avoid caching if the function is a closure because it then becomes a can
of worms (if the argument is not hashable etc). Throw a warning in that
case.
Fix #1108
fix(json): don't leak when lambdas are used as loads function