build(deps): Bump the major group across 1 directory with 3 updates by dependabot[bot] · Pull Request #33 · ckir/corelib

dependabot · 2026-11-09T07:03:23Z

Bumps the major group with 3 updates in the / directory: croner, postgres and graphql.

Updates croner from 10.0.1 to 11.0.0

Release notes

11.0.0

Croner 11.0.0 is a major release focused on correctness and predictability: DST handling aligned with croner-rust and Vixie cron, a new iterator API, and a long list of scheduling fixes around timezones, clock changes and edge-case patterns.

Highlights

Iterator API — The new enumerate() method returns a stateful CronIterator that works with for...of, destructuring, next(), peek() and reset(), and honors maxRuns.

Predictable DST handling — DST transitions now work as in croner-rust and Vixie cron. Fixed-time jobs in a spring-forward gap run at the first valid time after it, and interval jobs keep running through the repeated hour at fall back. Negative timer re-arming during fall back is fixed.

Inclusive startAt — A pattern match exactly at startAt now runs.

dayOffset that matches reality — nextRun(), nextRuns(), previousRuns(), msToNext() and enumerate() return actual run times, the same ones the scheduler uses.

Date-based jobs for "now" — A one-off job dated up to 1 second in the past fires immediately. The new allowPast option lets older dates fire too.

Faster timezone scheduling — Intl.DateTimeFormat instances are cached per timezone.

Timezone and clock robustness — ISO 8601 strings are read in the job's timezone/utcOffset, and scheduling recovers properly after system clock steps forward or backward.

Breaking Changes

DST handling aligned with croner-rust and Vixie cron, deliberately deviating from OCPS 1.4 §4.3.1 (0 30 2 * * * in a DST gap now runs at 3:00 AM instead of 3:30 AM, and interval jobs run on both occurrences of a repeated time)

startAt is inclusive (not when interval is set)

With dayOffset, nextRun() and related methods return actual run times, and startAt/stopAt apply to the shifted run time

previousRun() returns when the previous run started, as documented, instead of when it finished

See the migration guide further down for a smooth upgrade from 10.x.

Thank you to all contributors, and a special welcome to @SynthLuvr, @exceptdev, @EmersonBraun, @premsreelathasugeendran, @bensynapse, @youdie006, @sarmah-rup, @Shaisolaris and @cristianchiriac for their first contributions! 🎉

Details

Breaking changes

DST handling aligned with croner-rust and Vixie cron, deviating from OCPS 1.4 §4.3.1: jobs are either fixed-time jobs (one value each for seconds, minutes and hours) or interval jobs.

A fixed-time job in a DST gap (spring forward) runs at the first valid time after the gap. In 10.x it ran as much later as the gap was long (0 30 2 * * * ran at 3:30 AM, now 3:00 AM).

An interval job runs on both occurrences of a time repeated by a DST overlap (fall back), so * * * * * keeps running through the repeated hour (#343, #407). Patterns with more than one hour, minute or second, like 0 30 1,2 * * *, are interval jobs.

Fixed-time jobs still run once, at the first occurrence, in a DST overlap.

startAt is inclusive: a pattern match exactly at startAt now runs. Previously the first run was the following match. This does not apply with interval set, which works as in 10.x. A startAt between two whole seconds counts from the next whole second, and a run in the same second before a fractional stopAt (00:00:00 with stopAt 00:00:00.500) now runs. 10.x excluded it.

With dayOffset, nextRun(), nextRuns(), previousRuns(), msToNext() and enumerate() return actual run times, searched from the reference, the same way the scheduler and isRunning() do. Previously they shifted the next pattern match after the reference, so a negative offset could return a time before the reference, and msToNext() ignored the offset. startAt and stopAt also apply to the shifted run time. In 10.x they applied to the unshifted pattern match, so a job could run before startAt or after stopAt.

previousRun() returns when the previous run started, as documented. Previously it returned when the run finished.

Added

enumerate(startAt?) method returning a stateful CronIterator that supports iterator/iterable protocols (for...of, destructuring, next(), peek(), reset()) and honors maxRuns (#365). The CronIterator class is exported.

allowPast option for explicitly allowing date-based jobs scheduled more than 1 second in the past to fire immediately (#349).

CatchCallbackFn, CronMode and ProtectCallbackFn are exported from the source entry point (JSR). The npm type declarations already exposed them.

Changed

... (truncated)

Changelog

Sourced from croner's changelog.

[11.0.0] - 2026-10-25

Breaking changes

DST handling aligned with croner-rust and Vixie cron, deviating from OCPS 1.4 §4.3.1: jobs are either fixed-time jobs (one value each for seconds, minutes and hours) or interval jobs.

A fixed-time job in a DST gap (spring forward) runs at the first valid time after the gap. In 10.x it ran as much later as the gap was long (0 30 2 * * * ran at 3:30 AM, now 3:00 AM).

An interval job runs on both occurrences of a time repeated by a DST overlap (fall back), so * * * * * keeps running through the repeated hour (#343, #407). Patterns with more than one hour, minute or second, like 0 30 1,2 * * *, are interval jobs.

Fixed-time jobs still run once, at the first occurrence, in a DST overlap.

startAt is inclusive: a pattern match exactly at startAt now runs. Previously the first run was the following match. This does not apply with interval set, which works as in 10.x. A startAt between two whole seconds counts from the next whole second, and a run in the same second before a fractional stopAt (00:00:00 with stopAt 00:00:00.500) now runs. 10.x excluded it.

With dayOffset, nextRun(), nextRuns(), previousRuns(), msToNext() and enumerate() return actual run times, searched from the reference, the same way the scheduler and isRunning() do. Previously they shifted the next pattern match after the reference, so a negative offset could return a time before the reference, and msToNext() ignored the offset. startAt and stopAt also apply to the shifted run time. In 10.x they applied to the unshifted pattern match, so a job could run before startAt or after stopAt.

previousRun() returns when the previous run started, as documented. Previously it returned when the run finished.

Added

enumerate(startAt?) method returning a stateful CronIterator that supports iterator/iterable protocols (for...of, destructuring, next(), peek(), reset()) and honors maxRuns (#365). The CronIterator class is exported.

allowPast option for explicitly allowing date-based jobs scheduled more than 1 second in the past to fire immediately (#349).

CatchCallbackFn, CronMode and ProtectCallbackFn are exported from the source entry point (JSR). The npm type declarations already exposed them.

Changed

Cached Intl.DateTimeFormat instances per timezone, making timezone-aware scheduling noticeably faster (based on #389).

Date-based jobs dated up to 1 second in the past now fire immediately, so a job created for "now" is not lost to the time it took to create it. Older dates fire only with allowPast: true. Previously a date-based job in the past never fired (#348, #349).

Clarified dayOffset JSDoc and completed missing option documentation, including iterator usage, allowPast, and DST behavior.

Updated the copyright year to 2026.

Fixed

Fixed timers being re-armed with negative delays throughout the repeated hour of a DST fall back

... (truncated)

Commits

2df1672 Merge pull request #425 from Hexagon/dev
ecf62fd Release review fixes for 11.0.0 (#426)
b02a7a8 CI: run tests on master instead of main
0e9e034 Bump version to 11.0.0
4f2d08f Release prep: changelog corrections and docs cleanup for 11.0.0 (#421)
2b4597e Fix CronDate ignoring field changes after construction (#422)
b16eee9 Fix documentation examples that throw or are invalid (#423)
2024e6b Keep milliseconds in ISO strings, compare one-off dates with exact startAt (#...
e68341b Fix npm provenance: match repository.url casing to GitHub repo (#420)
8dd3714 Bump version to 11.0.0-dev.9
Additional commits viewable in compare view

Maintainer changes

This version was pushed to npm by GitHub Actions, a new releaser for croner since your current version.

Updates postgres from 3.4.9 to 4.1.0

Release notes

Sourced from postgres's releases.

v4.1.0

New

query_timeout (#1278). Seconds a query may take, waiting for a connection and running together, before it is canceled and rejects with QUERY_TIMEOUT. Off by default. Unlike statement_timeout it also ends a query whose server or network has gone silent, which TCP alone takes many minutes to notice. Transaction control queries and forEach are limited too; cursors, streams and sql.listen are not.

cancel_timeout, 5 seconds by default: how long a canceled query may take to end before its connection is closed.

sql.batch([queries]) sends queries in one round trip with a single Sync: outside a transaction they commit or roll back together, and the batch rejects with the failing query's position in error.index.

json on a transform (#1169). The built-in transforms rename the keys of JSON values in results but send JSON values as they are. json: false leaves JSON values as they are both ways, and json: true renames their keys when sending too, with the transform's column.to. Without it nothing changes.

eager_types: true reads array types and domains when the pool starts instead of when a query first meets one.

sql.identifier(...parts) (#1292). An identifier from its parts, each quoted as it is and joined with ., for a name that contains a dot, which sql(name) reads as a separator: sql.identifier('acme.inc', 'users') gives "acme.inc"."users". The transform is not applied. With no parts it throws NO_PARTS.

Node.js 18 is supported again: engines is >=18 and CI runs it. Nothing in Postgres.js needs 20; using, await using and tracing are used where the runtime has them. Loading it with require still needs Node.js 20.19 or 22.12.

sql`...`.parsers(parsers) (#1294). A query's own parsers, for its rows only: by type, { [oid]: parse }, on top of the instance's types, or a function that gets each column and returns the parser for it, null for the server's text. A library that knows how to decode some queries' columns can decode them once, inside the row reader, while every other query on the instance and its pool keeps the instance's parsers. Such a query receives every column as text, so bytea and the integer arrays otherwise read in binary reach its parsers as text. A query without .parsers() reads its rows as before.

Fixed

sql.listen keeps its connection after the last unlisten() (#1298). The connection was closed so the process could exit (#1022), which made every following listen() connect again: about 3.5 ms instead of 0.1 ms per listen. It now stays open without keeping the process alive once nothing is listened.

PGSSLMODE is read (#1307). It was ignored, so PGSSLMODE=verify-full connected in plain text without an error. This may change how existing setups connect: require now uses TLS and fails against a server without it, and verify-ca and verify-full check the certificate against Node's CAs, not ~/.postgresql/root.crt or PGSSLROOTCERT. A url or an ssl option still comes first.

An insert helper after a quoted schema and an unquoted table builds the insert (#1304). In insert into ${ sql('s') }.t ${ sql(row) } or insert into "s".t, the quoted schema and the table were read as two words, so the row was taken for a list of identifiers and threw x.replace is not a function.

sql.listen keeps reconnecting when its first reconnect fails (#1285, #1286). After the listen connection closed, it was reopened once, and if that attempt failed, as it does while a restarting server still refuses connections, nothing tried again, so onlisten was never called and notifications were lost. A failed reconnect is now retried after backoff, until it succeeds, the channel is unlistened or the pool ends.

A canceled query whose server never answers no longer waits forever. .cancel(), .signal() and now query_timeout send a cancel request and waited for the server to end the query, so a server or network gone silent left both the query and the promise .cancel() returns pending until TCP gave up. This applies to every cancel, also without query_timeout: when the server doesn't answer within cancel_timeout, the connection is closed and the pool connects again. Whether the queries on it ran is unknown, so they reject with CONNECTION_DESTROYED (a timed out one with QUERY_TIMEOUT) whose cause is CANCEL_UNANSWERED, not with 57014. The cancel request's own connection is limited by cancel_timeout too, and a cancel is no longer sent for a query whose result has already arrived, where it could only hit the query after it. A cancel request whose own connection fails, as over TLS to a server gone silent, no longer crashes the process with an unhandled rejection. A query that times out while it waits behind another one on its connection is canceled only after it has had its own query_timeout once its turn comes, instead of the moment its turn comes, when it had usually finished and the cancel stopped the next query; if the server sends nothing for cancel_timeout while it waits, the connection is closed. A query waiting for types to be read rejects with QUERY_TIMEOUT without closing its connection, and the read of array types and domains is limited by query_timeout too.

sslrootcert, sslcert and sslkey in a url are used (#1308). They were sent to the server as startup parameters, so ?sslrootcert=system failed with unrecognized configuration parameter. Files are read into ca, cert and key. As in libpq, a root certificate with require or verify-ca checks the CA but not the host name, and verify-full checks both, as does ssl: true. A file without an sslmode means require.

A transaction the server ends rejects with the server's error (#1283, #1284). When a transaction_timeout (25P04), an idle_in_transaction_session_timeout (25P03) or pg_terminate_backend (57P01) ended the session, sql.begin rejected with CONNECTION_CLOSED, so a timeout or a termination looked the same as a network drop; it now rejects with the FATAL error the server sent before closing, as a query in flight already did, and a later query on that connection rejects with CONNECTION_CLOSED that has it as cause. A server restart or failover ends sessions with 57P01, so code that retries a transaction on CONNECTION_CLOSED should retry on that code too. A FATAL in answer to COMMIT rejects with CONNECTION_CLOSED that has it as cause, as the outcome is unknown, as it is when the connection is lost during COMMIT.

A server certificate is verified against an IP host (#1309). With ssl: 'verify-full' or ssl: true and an IP as the host, a connection upgraded to TLS checked the certificate against localhost, so a certificate for localhost from a trusted CA passed for any IP and a correct certificate for the IP failed. Direct TLS was not affected.

A savepoint or nested begin rejects when its transaction's connection is lost (#1281, #1282). One whose callback was still running when the connection went resolved with the callback's result after the transaction had already rejected; it now rejects with the transaction's error.

A connection closed while the pool reads its array and domain types counts as a failed connection attempt (#1279). Reconnecting follows backoff and waiting queries reject once connect_timeout has passed, instead of reconnecting as fast as the server accepts for as long as it keeps closing. With connect_timeout set to 0, null or false the pool now keeps trying for as long as it takes, as the option says, also after a refused or closed startup, which used to reject the waiting queries at once.

A query failed by a FATAL error gives that error to the queries pipelined behind it as well, instead of CONNECTION_CLOSED.

A FATAL error with the severity only in the S field is recognised as one. The non-localized V field is optional in the protocol: PostgreSQL sends it since 9.6, and a pooler that builds its own errors, such as PgBouncer, may send only the localized S. Such an error was not seen as FATAL, so the query, a sql.begin and the queries pipelined behind it rejected with CONNECTION_CLOSED without a cause instead of with the error. error.severity now falls back to severity_local when V is missing.

Each query on a connection that closes gets its own error. They shared one error object, so every query pipelined on the connection reported the first one's query and parameters.

A cached prepared statement no longer keeps the query that prepared it (#1287). Each connection's entry for a prepared statement kept that query's values and rows for as long as the statement stayed cached, up to 1,000 statements per connection, so an app with many distinct statements grew by their results until every cache was full: about 1.1 GB with 10 connections and 50-row results. They are let go once the query settles. On 4.0.0, prepare: false avoids it.

Destroying a copy ... to stdout stream frees the connection (#1306). After destroy(), breaking out of for await or a failed pipeline, the connection stayed paused for good and the queries behind it never ran. The rest of the copy is now read and dropped, so the connection is free once the server has sent it. The query is not canceled, so in a transaction the next query still succeeds.

Performance

An ssl object with a ca builds its TLS context once (#1280). The connections made with it share one context instead of each parsing the whole ca list again, so with a provider's CA bundle a new connection takes about half the time and CPU, and a burst of them no longer blocks the event loop. Replacing one of the object's values, as with a renewed cert, builds a new context for the connections after it.

A new statement whose untyped values are all numbers or null is prepared, described and run in one round trip, as one whose parameter types are all known is, since those values are written the same for any type the server picks; one with other values only the server can type is still described first, once per connection.

Array types and domains are read when a query first meets a type the pool does not know (an oid from 16384 up), instead of when the pool starts: a pool that only uses built-in types never sends that query, and a new pool's first query costs no more than any other. The connection that met the type waits for it, read on another connection. With custom types given by name they are still read at startup, as their oids are needed before the first query. Leases and values typed as a type the pool hasn't read yet still wait for it. A read whose connection fails is retried after backoff, and once connect_timeout has passed the connections waiting for it are closed and their queries reject, as for a failed startup. eager_types: true reads them when the pool starts, as before.

timestamptz, and timestamp and date read as UTC, are decoded straight from the bytes when they use the built-in parsers, with the text parser for anything else (BC, infinity, years before 1000); about 20% more rows per second for rows with timestamps.

bytea and arrays of int2, int4, int8 and bool are fetched in binary once a prepared statement's columns are known on the connection, when they use the built-in parsers: the values are the same as from the text, about 4.5 times faster to read for bytea and 3 times for an int4[]. A custom parser for the type or its elements, and raw(), still get the text.

A connection that becomes ready while others are still opening no longer takes the queries meant for those; 50 connections opened at once each run one of 50 queries.

v4.0.0

v4 rewrites everything below the public API: the pool, the connection, the protocol, startup and the socket layer. Queries, helpers, transactions, cursors, COPY, listen, subscribe, large objects and the options work as in 3.4.9, apart from the changes below.

Security

A NUL character in a connection parameter can no longer add parameters (also in v3). A database, user or connection value such as 'db\0user\0postgres' was sent as further startup parameters, so an app that put untrusted input there, as with a database per tenant, could be made to log in as another user where that user needs no password, or with replication or options set. A NUL in any protocol string, also in query text and identifiers, now rejects with NUL_CHARACTER.

A column named __proto__ is an own property (also in v3). It became the prototype of the row, so a JSON value in it, for instance from a column alias built from user input, made the row inherit its properties (row.isAdmin), in query results and in sql.subscribe rows alike.

Upgrading from v3

The README has an upgrade guide, with a query that shows whether the change in parameter types concerns you.

... (truncated)

Changelog

Sourced from postgres's changelog.

v4.1.0 - 5 November 2026

New

query_timeout (#1278). Seconds a query may take, waiting for a connection and running together, before it is canceled and rejects with QUERY_TIMEOUT. Off by default. Unlike statement_timeout it also ends a query whose server or network has gone silent, which TCP alone takes many minutes to notice. Transaction control queries and forEach are limited too; cursors, streams and sql.listen are not.

cancel_timeout, 5 seconds by default: how long a canceled query may take to end before its connection is closed.

sql.batch([queries]) sends queries in one round trip with a single Sync: outside a transaction they commit or roll back together, and the batch rejects with the failing query's position in error.index.

json on a transform (#1169). The built-in transforms rename the keys of JSON values in results but send JSON values as they are. json: false leaves JSON values as they are both ways, and json: true renames their keys when sending too, with the transform's column.to. Without it nothing changes.

eager_types: true reads array types and domains when the pool starts instead of when a query first meets one.

sql.identifier(...parts) (#1292). An identifier from its parts, each quoted as it is and joined with ., for a name that contains a dot, which sql(name) reads as a separator: sql.identifier('acme.inc', 'users') gives "acme.inc"."users". The transform is not applied. With no parts it throws NO_PARTS.

Node.js 18 is supported again: engines is >=18 and CI runs it. Nothing in Postgres.js needs 20; using, await using and tracing are used where the runtime has them. Loading it with require still needs Node.js 20.19 or 22.12.

sql`...`.parsers(parsers) (#1294). A query's own parsers, for its rows only: by type, { [oid]: parse }, on top of the instance's types, or a function that gets each column and returns the parser for it, null for the server's text. A library that knows how to decode some queries' columns can decode them once, inside the row reader, while every other query on the instance and its pool keeps the instance's parsers. Such a query receives every column as text, so bytea and the integer arrays otherwise read in binary reach its parsers as text. A query without .parsers() reads its rows as before.

Fixed

sql.listen keeps its connection after the last unlisten() (#1298). The connection was closed so the process could exit (#1022), which made every following listen() connect again: about 3.5 ms instead of 0.1 ms per listen. It now stays open without keeping the process alive once nothing is listened.

PGSSLMODE is read (#1307). It was ignored, so PGSSLMODE=verify-full connected in plain text without an error. This may change how existing setups connect: require now uses TLS and fails against a server without it, and verify-ca and verify-full check the certificate against Node's CAs, not ~/.postgresql/root.crt or PGSSLROOTCERT. A url or an ssl option still comes first.

An insert helper after a quoted schema and an unquoted table builds the insert (#1304). In insert into ${ sql('s') }.t ${ sql(row) } or insert into "s".t, the quoted schema and the table were read as two words, so the row was taken for a list of identifiers and threw x.replace is not a function.

sql.listen keeps reconnecting when its first reconnect fails (#1285, #1286). After the listen connection closed, it was reopened once, and if that attempt failed, as it does while a restarting server still refuses connections, nothing tried again, so onlisten was never called and notifications were lost. A failed reconnect is now retried after backoff, until it succeeds, the channel is unlistened or the pool ends.

A canceled query whose server never answers no longer waits forever. .cancel(), .signal() and now query_timeout send a cancel request and waited for the server to end the query, so a server or network gone silent left both the query and the promise .cancel() returns pending until TCP gave up. This applies to every cancel, also without query_timeout: when the server doesn't answer within cancel_timeout, the connection is closed and the pool connects again. Whether the queries on it ran is unknown, so they reject with CONNECTION_DESTROYED (a timed out one with QUERY_TIMEOUT) whose cause is CANCEL_UNANSWERED, not with 57014. The cancel request's own connection is limited by cancel_timeout too, and a cancel is no longer sent for a query whose result has already arrived, where it could only hit the query after it. A cancel request whose own connection fails, as over TLS to a server gone silent, no longer crashes the process with an unhandled rejection. A query that times out while it waits behind another one on its connection is canceled only after it has had its own query_timeout once its turn comes, instead of the moment its turn comes, when it had usually finished and the cancel stopped the next query; if the server sends nothing for cancel_timeout while it waits, the connection is closed. A query waiting for types to be read rejects with QUERY_TIMEOUT without closing its connection, and the read of array types and domains is limited by query_timeout too.

sslrootcert, sslcert and sslkey in a url are used (#1308). They were sent to the server as startup parameters, so ?sslrootcert=system failed with unrecognized configuration parameter. Files are read into ca, cert and key. As in libpq, a root certificate with require or verify-ca checks the CA but not the host name, and verify-full checks both, as does ssl: true. A file without an sslmode means require.

A transaction the server ends rejects with the server's error (#1283, #1284). When a transaction_timeout (25P04), an idle_in_transaction_session_timeout (25P03) or pg_terminate_backend (57P01) ended the session, sql.begin rejected with CONNECTION_CLOSED, so a timeout or a termination looked the same as a network drop; it now rejects with the FATAL error the server sent before closing, as a query in flight already did, and a later query on that connection rejects with CONNECTION_CLOSED that has it as cause. A server restart or failover ends sessions with 57P01, so code that retries a transaction on CONNECTION_CLOSED should retry on that code too. A FATAL in answer to COMMIT rejects with CONNECTION_CLOSED that has it as cause, as the outcome is unknown, as it is when the connection is lost during COMMIT.

A server certificate is verified against an IP host (#1309). With ssl: 'verify-full' or ssl: true and an IP as the host, a connection upgraded to TLS checked the certificate against localhost, so a certificate for localhost from a trusted CA passed for any IP and a correct certificate for the IP failed. Direct TLS was not affected.

A savepoint or nested begin rejects when its transaction's connection is lost (#1281, #1282). One whose callback was still running when the connection went resolved with the callback's result after the transaction had already rejected; it now rejects with the transaction's error.

A connection closed while the pool reads its array and domain types counts as a failed connection attempt (#1279). Reconnecting follows backoff and waiting queries reject once connect_timeout has passed, instead of reconnecting as fast as the server accepts for as long as it keeps closing. With connect_timeout set to 0, null or false the pool now keeps trying for as long as it takes, as the option says, also after a refused or closed startup, which used to reject the waiting queries at once.

A query failed by a FATAL error gives that error to the queries pipelined behind it as well, instead of CONNECTION_CLOSED.

A FATAL error with the severity only in the S field is recognised as one. The non-localized V field is optional in the protocol: PostgreSQL sends it since 9.6, and a pooler that builds its own errors, such as PgBouncer, may send only the localized S. Such an error was not seen as FATAL, so the query, a sql.begin and the queries pipelined behind it rejected with CONNECTION_CLOSED without a cause instead of with the error. error.severity now falls back to severity_local when V is missing.

Each query on a connection that closes gets its own error. They shared one error object, so every query pipelined on the connection reported the first one's query and parameters.

A cached prepared statement no longer keeps the query that prepared it (#1287). Each connection's entry for a prepared statement kept that query's values and rows for as long as the statement stayed cached, up to 1,000 statements per connection, so an app with many distinct statements grew by their results until every cache was full: about 1.1 GB with 10 connections and 50-row results. They are let go once the query settles. On 4.0.0, prepare: false avoids it.

Destroying a copy ... to stdout stream frees the connection (#1306). After destroy(), breaking out of for await or a failed pipeline, the connection stayed paused for good and the queries behind it never ran. The rest of the copy is now read and dropped, so the connection is free once the server has sent it. The query is not canceled, so in a transaction the next query still succeeds.

Performance

An ssl object with a ca builds its TLS context once (#1280). The connections made with it share one context instead of each parsing the whole ca list again, so with a provider's CA bundle a new connection takes about half the time and CPU, and a burst of them no longer blocks the event loop. Replacing one of the object's values, as with a renewed cert, builds a new context for the connections after it.

A new statement whose untyped values are all numbers or null is prepared, described and run in one round trip, as one whose parameter types are all known is, since those values are written the same for any type the server picks; one with other values only the server can type is still described first, once per connection.

Array types and domains are read when a query first meets a type the pool does not know (an oid from 16384 up), instead of when the pool starts: a pool that only uses built-in types never sends that query, and a new pool's first query costs no more than any other. The connection that met the type waits for it, read on another connection. With custom types given by name they are still read at startup, as their oids are needed before the first query. Leases and values typed as a type the pool hasn't read yet still wait for it. A read whose connection fails is retried after backoff, and once connect_timeout has passed the connections waiting for it are closed and their queries reject, as for a failed startup. eager_types: true reads them when the pool starts, as before.

timestamptz, and timestamp and date read as UTC, are decoded straight from the bytes when they use the built-in parsers, with the text parser for anything else (BC, infinity, years before 1000); about 20% more rows per second for rows with timestamps.

bytea and arrays of int2, int4, int8 and bool are fetched in binary once a prepared statement's columns are known on the connection, when they use the built-in parsers: the values are the same as from the text, about 4.5 times faster to read for bytea and 3 times for an int4[]. A custom parser for the type or its elements, and raw(), still get the text.

A connection that becomes ready while others are still opening no longer takes the queries meant for those; 50 connections opened at once each run one of 50 queries.

v4.0.0 - 29 October 2026

v4 rewrites everything below the public API: the pool, the connection, the protocol, startup and the socket layer. Queries, helpers, transactions, cursors, COPY, listen, subscribe, large objects and the options work as in 3.4.9, apart from the changes below.

Security

A NUL character in a connection parameter can no longer add parameters (also in v3). A database, user or connection value such as 'db\0user\0postgres' was sent as further startup parameters, so an app that put untrusted input there, as with a database per tenant, could be made to log in as another user where that user needs no password, or with replication or options set. A NUL in any protocol string, also in query text and identifiers, now rejects with NUL_CHARACTER.

A column named __proto__ is an own property (also in v3). It became the prototype of the row, so a JSON value in it, for instance from a column alias built from user input, made the row inherit its properties (row.isAdmin), in query results and in sql.subscribe rows alike.

Upgrading from v3

... (truncated)

Commits

d84da74 4.1.0
ed622d1 Don't use prepublish
4755e68 Please the linter
f7e795f Update changelog
45b226f Verify the server certificate against an IP host instead of localhost
4ffacc8 Keep the full check for ssl true with certificates in the url
84b8e28 Use sslrootcert, sslcert and sslkey from a url instead of sending them to the...
19db087 Add PGSSLMODE to the changelog
607b20b Read PGSSLMODE
875edc3 Drain a destroyed copy read stream instead of canceling it
Additional commits viewable in compare view

Updates graphql from 16.14.2 to 16.15.0

Release notes

Sourced from graphql's releases.

v16.15.0 (2026-11-04)

New Feature 🚀

#4984 Backport work to v16 (@yaacovCR)

Backports:

[Fix performance issue with ESLint (#3586)](graphql/graphql-js#3586)

[refactor: add map keyed by set membership (#4836)](graphql/graphql-js#4836)

[perf: reuse fragment dependencies across operations (#4920)](graphql/graphql-js#4920)

[perf: reuse fragment variable usages (#4921)](graphql/graphql-js#4921)

[perf: share fragment collection across operations (#4925)](graphql/graphql-js#4925)

[refactor: track fragment validation work (#4946)](graphql/graphql-js#4946)

[refactor: simplify referenced fragment collection (#4948)](graphql/graphql-js#4948)

[perf: share subscription fragment lookups (#4927)](graphql/graphql-js#4927)

[refactor: extract visitSelectionSets (#4947)](graphql/graphql-js#4947)

[refactor: account for subscription field collection (#4949)](graphql/graphql-js#4949)

[perf: reuse identical field return types (#4940)](graphql/graphql-js#4940)

[perf: reuse field return type names (#4941)](graphql/graphql-js#4941)

[perf: reuse field return type descriptions (#4944)](graphql/graphql-js#4944)

[refactor: account for field return type comparisons (#4951)](graphql/graphql-js#4951)

[perf: skip selection sets with no fields to compare (#4960)](graphql/graphql-js#4960)

[perf: skip pair metadata for compatible leaf fields (#4964)](graphql/graphql-js#4964)

[perf: reuse introspection fragment checks (#4932)](graphql/graphql-js#4932)

[perf: reuse fragment checks from fields exceeding the introspection depth (#4971)](graphql/graphql-js#4971)

[perf: share source location lookups (#4936)](graphql/graphql-js#4936)

[perf: scan single source locations directly (#4958)](graphql/graphql-js#4958)

[refactor: stream printer output (#4952)](graphql/graphql-js#4952)

[feat: configure printer indentation depth (#4953)](graphql/graphql-js#4953)

[perf: flatten input-value printing (#4972)](graphql/graphql-js#4972)

[perf: avoid arrays for single-line printer text (#4973)](graphql/graphql-js#4973)

[perf: assemble printer output as a string (#4974)](graphql/graphql-js#4974)

[perf: skip empty printer work (#4975)](graphql/graphql-js#4975)

[perf: add a minimal AST reducer for printing (#4976)](graphql/graphql-js#4976)

[perf: index directive argument names (#4942)](graphql/graphql-js#4942)

[feat: Allow skipping suggestions (#4214)](graphql/graphql-js#4214)

[fix: skip disabled argument suggestions (#4937)](graphql/graphql-js#4937)

[fix(execute): handle defaultTypeResolver promise rejections (#4646)](graphql/graphql-js#4646)

[fix(mapAsyncIterable): always close source when mapped iterable is thrown (#4494)](graphql/graphql-js#4494)

[fix(valueFromAST): forward port #4652 (#4671)](graphql/graphql-js#4671)

[fix: avoid inherited variable getters in nested literal values (#4983)](graphql/graphql-js#4983)

[fix(changelog): ignore open associated PRs (#4723)](graphql/graphql-js#4723)

Bug Fix 🐞

#4900 Backport OverlappingFieldsCanMerge changes (v16) (@yaacovCR)

#4909 Backport maxLexicalTokens, maxComments, maxSourceLength parser options (v16) (@yaacovCR)

#4917 fix: bound shared fragment traversal in introspection validation (v16) (@yaacovCR)

Docs 📝

... (truncated)

Commits

2b4f68f chore(release): v16.15.0
eec0d85 fix(changelog): ignore open associated PRs (v16 backport #4723)
5dd629e fix: avoid inherited variable getters in nested literal values (v16 backport ...
f777e44 fix(valueFromAST): restore variable own-property checks (v16 backport #4671)
24dc09d fix(mapAsyncIterable): always close source when mapped iterable is thrown (v1...
19f7df5 fix(execute): handle defaultTypeResolver promise rejections (v16 backport #4646)
e596845 fix: skip disabled argument suggestions (v16 backport #4937)
ce8dab2 feat: Allow skipping suggestions (v16 backport #4214)
8c1b676 perf: index directive argument names (v16 backport #4942)
c287ea5 perf: add a minimal AST reducer for printing (v16 backport #4976)
Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

@dependabot rebase will rebase this PR
@dependabot recreate will recreate this PR, overwriting any edits that have been made to it
@dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
@dependabot ignore <dependency name> major version will close this group update PR and stop Dependabot creating any more for the specific dependency's major version (unless you unignore this specific dependency's major version or upgrade to it yourself)
@dependabot ignore <dependency name> minor version will close this group update PR and stop Dependabot creating any more for the specific dependency's minor version (unless you unignore this specific dependency's minor version or upgrade to it yourself)
@dependabot ignore <dependency name> will close this group update PR and stop Dependabot creating any more for the specific dependency (unless you unignore this specific dependency or upgrade to it yourself)
@dependabot unignore <dependency name> will remove all of the ignore conditions of the specified dependency
@dependabot unignore <dependency name> <ignore condition> will remove the ignore condition of the specified dependency and ignore conditions

Bumps the major group with 3 updates in the / directory: [croner](https://github.com/Hexagon/croner), [postgres](https://github.com/porsager/postgres) and [graphql](https://github.com/graphql/graphql-js). Updates `croner` from 10.0.1 to 11.0.0 - [Release notes](https://github.com/Hexagon/croner/releases) - [Changelog](https://github.com/Hexagon/croner/blob/master/CHANGELOG.md) - [Commits](Hexagon/croner@10.0.1...11.0.0) Updates `postgres` from 3.4.9 to 4.1.0 - [Release notes](https://github.com/porsager/postgres/releases) - [Changelog](https://github.com/porsager/postgres/blob/master/CHANGELOG.md) - [Commits](porsager/postgres@v3.4.9...v4.1.0) Updates `graphql` from 16.14.2 to 16.15.0 - [Release notes](https://github.com/graphql/graphql-js/releases) - [Commits](graphql/graphql-js@v16.14.2...v16.15.0) --- updated-dependencies: - dependency-name: croner dependency-version: 11.0.0 dependency-type: direct:production update-type: version-update:semver-major dependency-group: major - dependency-name: postgres dependency-version: 4.1.0 dependency-type: direct:production update-type: version-update:semver-major dependency-group: major - dependency-name: graphql dependency-version: 16.15.0 dependency-type: indirect update-type: version-update:semver-minor dependency-group: major ... Signed-off-by: dependabot[bot] <support@github.com>

dependabot · 2026-11-09T07:03:26Z

Labels

The following labels could not be found: dependencies, npm. Please create them before Dependabot can add them to a pull request.

Please fix the above issues or remove invalid values from dependabot.yml.

dependabot Bot requested a review from ckir as a code owner November 9, 2026 07:03

Navigation Menu

Repository navigation

build(deps): Bump the major group across 1 directory with 3 updates - #33

build(deps): Bump the major group across 1 directory with 3 updates#33
dependabot[bot] wants to merge 1 commit into
mainfrom
dependabot/npm_and_yarn/major-95768bdd82

dependabot Bot commented on behalf of github Nov 9, 2026

Uh oh!

dependabot Bot commented on behalf of github Nov 9, 2026

Uh oh!

This branch has not been deployed

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

0 participants

Conversation

dependabot Bot commented on behalf of github Nov 9, 2026

11.0.0

Highlights

Breaking Changes

Details

Breaking changes

Added

Changed

[11.0.0] - 2026-10-25

Breaking changes

Added

Changed

Fixed

v4.1.0

New

Fixed

Performance

v4.0.0

Security

Upgrading from v3

v4.1.0 - 5 November 2026

New

Fixed

Performance

v4.0.0 - 29 October 2026

Security

Upgrading from v3

v16.15.0 (2026-11-04)

New Feature 🚀

Bug Fix 🐞

Docs 📝

Uh oh!

dependabot Bot commented on behalf of github Nov 9, 2026

Labels

Uh oh!

This branch has not been deployed

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

0 participants