fix: epoch-encoding bugs — timestamp equality/IN returns ZERO rows on compressed partitions

[wezell]

Confirmed live on postgres-ovh-east (dot_token)

Any equality or IN-list predicate on a timestamp column against a compressed partition silently returns zero rows. Range predicates are correct, so this is invisible unless you look for it.

-- public.pingbacks_p20260810 (549 rows)
select count(*) from public.pingbacks_p20260810;                                    -- 549
select count(*) from ... where created_date =  '2026-08-10 06:18:41.502+00';        --   0  ← wrong
select count(*) from ... where created_date in ('2026-08-10 06:18:41.502+00');      --   0  ← wrong
select count(*) from ... where created_date >= '...' and created_date <= '...';      --   1  ← correct

-- public.telemetry_request_cost_p20260815 (95,159 rows) — same, on both the
-- time column (received_at) and a non-time timestamp column (ts)
eq_timecol_const=0  eq_nontime_const=0  in_nontime_const=0  range=1

Blast radius: 625 compressed partitions across both deltatables (541 pingbacks + 84 telemetry_request_cost).

Root cause

Unix-epoch vs PostgreSQL-epoch (946,684,800 s offset) confusion in src/scan/exec/segments.rs — fixed upstream, never picked onto this branch:

• b3bcc69ca — the bloom build side (compress.rs) hashes TypedColumn values as Unix-epoch µs, while the probe side hashed the raw PG-epoch datum of the qual constant. Hashes never match → every segment falsely bloom-rejected. Also converts the meta-table min/max at load to match the colstats encoding contract (latent today, bites any new consumer).
• b57934975 — third epoch bug: the colstats min/max in-list filter identity-encoded PG-epoch datums for timestamp/date IN-lists on non-time columns, comparing against Unix-epoch-µs bounds → falsely pruned every segment. Routes all constant encoding (eq, range, in-list, bloom probe) through encode_datum_to_i64, and skips minmax pruning entirely when an element is unencodable rather than risk a wrong prune.

This PR

Cherry-picks both upstream commits. src/scan/exec/segments.rs applied clean; the only conflict was an append-at-EOF collision in tests/test_compression.py between this branch's cross-schema tests and upstream's new TestEpochEncoding class — resolved by keeping both (no duplicate test names, file parses).

Brings upstream's regression coverage: bloom_probe_encode_matches_build_domain unit test + TestEpochEncoding (equality, IN-list, absent-value, DATE payload equality, MIN/MAX aggregate shapes, boundary ranges). The equality/IN cases fail without the fix.

No version bump — 0.2.0-dotcms.6 is already on the branch from #3 and is not yet tagged or released, so both fixes ship in one deb build and one image roll instead of two primary restarts.

Post-roll acceptance test

Re-run the exact probes above against the same two partitions; every 0 must become 1. Existing compressed partitions need no recompression — this is a read/probe-path fix only.

Upstream audit — what else was considered and skipped

dotcms-0.2.0 is v0.2.0 + 16 local commits; upstream main is 83 commits ahead. Reviewed all 83:

Upstream	Verdict
1897f4c8f jsonb segment restore	skip — restore_segment_rows is DML-era code that doesn't exist on 0.2.0; this branch's decompress path already routes jsonb through jsonb_binary_to_text (dotcms.5)
e41983706 sum with NaN literals	skip for now — 0 NaN rows live in the float8 columns; take on re-sync
5e800a8a5 xataio#53 RenderGucGuard	re-sync item — real data-loss class for fallback-typed columns, but squashed into a large PR and the maintenance worker runs default DateStyle/extra_float_digits
78ca3bf09 xataio#45 per-table error isolation	re-sync item — would have contained the dotcms.4 dead-worker incident, but 550 lines into worker.rs that collide with this branch's custom launcher
planner-stats (33 commits), DML-on-compressed, perf/condition-cache/prefetch	skip — features not in use here

Strategic note: upstream now carries its own target_database (xataio#38/xataio#39), this fork's non-text-column fix (xataio#51), and the ProcessUtility guard (xataio#25). The fork's unique delta is down to roughly the launcher pattern and version packaging — at the next upstream release, rebasing onto upstream main likely costs less than continuing to cherry-pick onto the 0.2.0 base.

Next steps (not done here)

Merge → tag v0.2.0-dotcms.6 on the merge commit (captures #3's ANALYZE guard and this) → release.yml builds the debs → bump ARG PG_DELTAX_VERSION in ovh-k8s-cluster's postgres-cnpg/Dockerfile (validate check races the release; re-run once assets exist) → digest-pinned roll of postgres-ovh-east.

🤖 Generated with Claude Code

https://claude.ai/code/session_01XGCecJYCz8dMTNPadEbeRf