use exact count when estimates fail#4393
Conversation
Code Review1 issue found. Checked for bugs and CLAUDE.md compliance. Bug: Fallback to precise count is unreachable after transaction abortFile: flow/connectors/postgres/qrep_partition.go, lines 472-476 pp.tx is a pgx.Tx created via BeginTx with RepeatableRead isolation. When the ::bigint cast overflows in the estimated count SQL query, PostgreSQL raises a server-side error that puts the transaction into an aborted state. All subsequent commands on that transaction will fail with current transaction is aborted, commands ignored until end of transaction block. This means the precise count fallback query at line 491 will also fail -- the fallback is unreachable in the overflow scenario this PR is designed to fix. Possible fixes:
|
19afc56 to
4f70a58
Compare
4f70a58 to
5da3830
Compare
❌ 2 Tests Failed:
View the top 2 failed test(s) by shortest run time
To view more test analytics, go to the Test Analytics Dashboard |
🔄 Flaky Test DetectedAnalysis: The single isolated subtest TestPeerFlowE2ETestSuitePG_CH/Test_Composite_PKey hit a 60s snapshot-status timeout (STATUS_SNAPSHOT never reached RUNNING) on a trivial 1-row table under heavy parallel CI load, with the unrelated PG-TLS HEAD commit — a classic resource-contention flake, not a real bug. ✅ Automatically retrying the workflow |
| if err := pp.tx.QueryRow(ctx, estimatedCountTemplate, pp.watermarkTable).Scan(&n); err != nil { | ||
| return 0, fmt.Errorf("failed to query for estimated row count: %w", err) | ||
| } else if v, err := n.Int64Value(); err != nil { | ||
| pp.logger.Warn("estimated row count outside int64 range, falling back to precise count", |
There was a problem hiding this comment.
Just a thought, could also query the inputs into the formula and log them for debugging purposes
Encountered a scenario where the query count estimate led to
ERROR: bigint out of range (SQLSTATE 22003); and the while the exact row count for the table is very low.The query is:
When stats are not populated due to a relatively new table, reltuples could be 0 or -1, and in both cases the result would not overflow. Given the actual row count is small, the most likely scenario seem to be table bloat with dead rows that led to both reltuples and pg_relation_size to be very high.
When we hit this error, we can conservatively fall back to actual table count.
Fixes: DBI-766