fix: close() nulls pool + connect() lock guards against concurrent races (psql-7, psql-8)

- close() sets self._pool = None (in a finally, even on driver-error close) so a closed
  instance reports not-connected instead of masquerading as still-connected against a
  dead pool (the pool property now raises RuntimeError post-close as intended).
- connect() is now guarded by an internal asyncio.Lock: concurrent connect() calls
  serialize instead of each racing to build + orphan its own live pool. Twin fix with
  mysql at the same Layer-1 signature level.
- docstrings tightened (module header lifecycle/dsn notes, __init__ dsn note) with zero
  behavior change; re-verified against a real embedded postgres.

verified against pixeltable-pgserver (test-only): 8 concurrent connect() calls now leave
0 orphaned pools + exactly 1 live pool (old: 7 orphaned, 8 live simultaneously); close()
now flips the connected-check to False (old: stayed True against a dead pool). full
layer-1/layer-2/transaction/concurrency regression suite still green. fresh-venv install
confirms runtime purity (asyncpg only, no pixeltable-pgserver). bump v0.1.4 -> v0.1.5

Signed-off-by: disqualifier <dev@disqualifier.me>

This commit is contained in:

dsql

2026-07-02 23:25:52 -04:00

parent 1ae280e5c3

commit f90c18ed64

3 changed files with 42 additions and 34 deletions

									
										pyproject.toml
									
		+1
		-1
	
												View File
												
				@@ -4,7 +4,7 @@ build-backend = "hatchling.build"

				[project]

				name = "psql"

				version = "0.1.4"

				version = "0.1.5"

				description = "async postgres wrapper over asyncpg: two-layer API (friendly verbs + raw escape hatch), fail-loud, config-free"

				requires-python = ">=3.10"

				dependencies = [