denis256 notes and projects

ingestr v1.0.64 was published on July 2, 2026, as a stable GitHub release for the ingestr project. The release fixes a Snowflake multi table write deadlock caused by connection pool exhaustion, which is exactly the kind of small change that matters when a data job hangs and gives little signal. It is not marked as a prerelease.

The full release notes and downloads are on the GitHub release page.

Snowflake multi table writes

The changelog for v1.0.64 lists one user facing fix. Snowflake multi table writes could deadlock when the connection pool was exhausted. The second changelog entry is the merge record for the same work, so there is no separate feature hidden in the notes.

That narrow scope is useful. If you use ingestr for Snowflake loads, this release points at a concrete failure mode: a run writing more than one table could get stuck because available connections were consumed. In a data pipeline, that kind of stall is worse than a clean error. The job may look alive, while the useful work has stopped.

The fix is about the write path, not a new destination, source, or command. The release notes do not mention a new flag, a new config key, or a changed Snowflake URI shape. Treat it as a reliability update for existing Snowflake workloads.

Connection pool exhaustion was the root cause

The important phrase in the notes is connection pool exhaustion. It tells operators where the bug lived. This was not described as a Snowflake permission issue, table naming issue, or warehouse setting problem. The failure was tied to the way connections were used during multi table writes.

That distinction matters during triage. When a write job stalls, the first guesses are often credentials, locks in the destination, warehouse capacity, or bad input data. This release says one more thing belongs on that list: the client side connection pool can be the thing that traps the run.

For teams that run ingestr jobs in schedulers, this fix should reduce one annoying class of silent waits. A stuck extraction or load can block later tasks, hold worker slots, and create false pressure on retry logic. Fixing the deadlock source is cleaner than asking the scheduler to paper over it.

What changes for operators

There are no breaking changes listed for v1.0.64. There are also no migration steps, deprecations, or manual cleanup notes in the release text. That makes the upgrade decision mostly about whether your ingestr deployment writes to Snowflake, especially when a single run handles several tables.

If Snowflake is not in your path, this release is still part of the normal version line, but the direct operational benefit is smaller. The notes do not claim broader connector changes. They do not mention BigQuery, Postgres, CDC, schema evolution, or source side behavior.

If Snowflake is in your path, the signal is simple. Upgrade when you can, then watch the next few multi table loads for the absence of hangs rather than for a visible new feature. That is not glamorous work, but it is the work that keeps batch windows boring.

This one is also useful for incident review because it names both the symptom and the cause. If a team saw stalled Snowflake loads before this version, v1.0.64 gives them a specific upstream fix to compare against. Some releases are just about making an existing path stop failing in a precise way.

Where to get it

• Release page: GitHub release page
• Repository: project repo
• Tag: v1.0.64