[jasperblues]

This fixes main, which is red on Python 3.14 since #428's merge (b33e2fd), in CI run 42118394771. The sync vector-index tests fail there with DiskFull: could not resize shared memory segment … to 63999616 bytes: No space left on device.

Cause

tests/*/sql/test_compiled_write_loop_time.py leaves pooled Postgres sessions holding /dev/shm. The first time a backend runs anything in parallel, it keeps a dynamic shared memory segment of about 1.2 MB until it disconnects, and the pool keeps backends connected. A parallel HNSW build asks for 63,999,616 bytes, which leaves about 3.1 MB of the 64 MB free. So the build fits while one session holds a segment, and fails once two do.

The test made two sessions hold one:

1. The VACUUM before the MERGE case. The async run's 20k MERGE grows the shared edge indexes past min_parallel_index_scan_size, and its final DELETE leaves 20,000 dead edges. The sync twin's VACUUM ANALYZE drivine_edge then vacuums those indexes in parallel. Across that statement, /dev/shm went from 1,075,552 to 2,320,864 bytes, and the pooled backend that ran it held the segment through the sync schema tests.
2. The emptied node table. The test left drivine_node with about 8 MB of dead rows, which is over min_parallel_table_scan_size. A later range-index build on it ran in parallel, and that build's backend held a second segment. The same table size is what makes the HNSW build parallel at all.

These were found by listing /dev/shm around each test with pg_ls_dir and pg_stat_file, and mapping each segment to its backend through /proc/<pid>/maps.

Whether the failure shows depends on autovacuum clearing the dead rows in time, which is why only some runs fail.

Fix

The fix is in the tests only:

• The VACUUM before the MERGE case is now VACUUM (PARALLEL 0, ANALYZE) drivine_edge. The table is still vacuumed empty there, so the case still drives A compiled MERGE of many relationships is quadratic on Postgres once the edge table is vacuumed empty #420's cause.
• After the final DELETE, on Postgres, the test runs VACUUM (PARALLEL 0) drivine_node, drivine_edge, which truncates the emptied tables.

With both, no backend held an extra segment at any point in a full run. Before every sync test_schema test, /dev/shm held only Postgres's own two segments. No shm size was raised, and nothing was skipped or marked xfail.

Follow-ups (next train)

• Postgres: a pooled session that built a schema index in parallel keeps its shared memory, so a later vector index can't be built in a 64 MB /dev/shm drivine4j#626, with ports Port of drivine4j#626: a pooled session that built a schema index in parallel keeps its shared memory, so a later vector index can't be built in a 64 MB /dev/shm drivine#641 and Port of drivine4j#626: a pooled session that built a schema index in parallel keeps its shared memory, so a later vector index can't be built in a 64 MB /dev/shm #435. Drivine's own schema index builds run on pooled sessions too, so an application with a large label can hit this.
• Docs: Docs: a vector index on a large label can fail on Postgres in a container with Docker's default 64 MB /dev/shm #432.

Gate

• ruff check, ruff format --check, pyright and unasync --check.
• The suite on Python 3.14, through the test lock.
• One review pass, which corrected one comment.