multica-ai/multica · error

connect to database: %w

Error message

connect to database: %w

What it means

pgxpool.New failed while parsing the DSN or initializing the connection pool for the task_usage_hourly backfill command. pgxpool.New only validates the config (connection string syntax, pool sizes, timeouts) — it does not contact the server, so this error almost always means the DSN itself is malformed or contains unsupported parameters. The default DSN is postgres://multica:multica@localhost:5432/multica?sslmode=disable, overridden by the command's -db flag/env.

Source

Thrown at server/cmd/backfill_task_usage_hourly/main.go:88

		sleep        = flag.Duration("sleep-between-slices", 0, "pause this long between monthly slices to throttle source-table read pressure on a busy DB (e.g. 2s)")
	)
	flag.Parse()

	dbURL := os.Getenv("DATABASE_URL")
	if dbURL == "" {
		dbURL = "postgres://multica:multica@localhost:5432/multica?sslmode=disable"
	}

	// SIGINT/SIGTERM cancels ctx so an in-flight slice stops cleanly —
	// each slice runs in its own transaction (the window function), so
	// Postgres rolls back the interrupted one and the idempotent design
	// lets a later run resume from where this one stopped.
	ctx, stop := signal.NotifyContext(context.Background(), os.Interrupt, syscall.SIGTERM)
	defer stop()

	pool, err := pgxpool.New(ctx, dbURL)
	if err != nil {
		return fmt.Errorf("connect to database: %w", err)
	}
	defer pool.Close()

	if err := pool.Ping(ctx); err != nil {
		return fmt.Errorf("ping database: %w", err)
	}

	// Serialise against the cron rollup and any other backfill run via
	// advisory lock 4246 — the same id the cron entry checks with
	// pg_try_advisory_lock. While this backfill holds it, the cron tick
	// no-ops instead of racing on task_usage_hourly row locks; a second
	// concurrent backfill blocks here until this one finishes. The lock
	// is held on a dedicated session connection for the whole run.
	lockConn, err := pool.Acquire(ctx)
	if err != nil {
		return fmt.Errorf("acquire advisory-lock connection: %w", err)
	}
	defer lockConn.Release()

View on GitHub (pinned to 2c0912b6ec)

Solutions

  1. Print/inspect the exact DSN being passed (flag or env) and validate its syntax with psql "<dsn>" -c 'select 1'
  2. Percent-encode reserved characters in the password portion of the URL
  3. Confirm every query parameter (sslmode, pool_max_conns, etc.) is spelled correctly and supported by pgxpool
  4. If the error text mentions parse failure on a key=value string, switch to URL form or a fully qualified libpq string pgx accepts

Example fix

// before
export DATABASE_URL='postgres://multica:p@ss@localhost:5432/multica'

// after
export DATABASE_URL='postgres://multica:p%40ss@localhost:5432/multica'
Defensive patterns

Strategy: validation

Validate before calling

if _, err := pgxpool.ParseConfig(dsn); err != nil {
    log.Fatalf("invalid DSN: %v", err)
}

Try / catch

if err != nil {
    return fmt.Errorf("connect to database: %w", err)
}

Prevention

When it happens

Trigger: Passing a DSN with a syntax error (e.g. missing scheme, bad query params), an unknown runtime parameter in the query string, or invalid pool settings (min_size > max_size). Also using a URL with special characters in the password that are not percent-encoded.

Common situations: Local dev without Postgres running is NOT this error (that surfaces at Ping); this is typos in DATABASE_URL, copy-pasting a libpq key=value string where a URL is expected, or %-unencoded passwords like p@ssw0rd.

Related errors


AI-assisted analysis of multica-ai/multica@2c0912b6ec (2026-08-15). Data as JSON: /api/errors/c5b15e0f395ce919. Report an issue: GitHub.