feat(pg-pg): introduce new MERGE statement leveraging jsonb_to_record#4167
feat(pg-pg): introduce new MERGE statement leveraging jsonb_to_record#4167Amogh-Bharadwaj merged 1 commit intomainfrom
Conversation
❌ 2 Tests Failed:
View the top 3 failed test(s) by shortest run time
To view more test analytics, go to the Test Analytics Dashboard |
❌ Test FailureAnalysis: Real bug: TestPeerFlowE2ETestSuitePG/Test_Types_PG_Legacy_Merge fails deterministically across all 3 CI jobs with a timezone mismatch (expected "06:25:00+00" but got "09:25:00+03"), indicating the pg-pg-better-merge changes broke timetz normalization in the legacy merge path. |
❌ Test FailureAnalysis: Deterministic timezone mismatch in |
❌ Test FailureAnalysis: Test_Types_QValue_New_Merge fails deterministically across all CI matrix jobs with identical data mismatches after normalization completes, indicating a real bug in type conversion rather than a flaky infrastructure issue. |
🔄 Possible Flaky TestAnalysis: The failures are in MySQL GTID and MariaDB e2e suites (binary encoding mismatch and long-running tests) while the triggering commit only touches Postgres slot activity logic, strongly suggesting pre-existing flaky e2e tests unrelated to the change. |
❌ Test FailureAnalysis: Tests |
❌ Test FailureAnalysis: Real bug: the pg-pg-better-merge PR introduced a regression in |
❌ Test FailureAnalysis: Real build failure: the field |
❌ Test FailureAnalysis: Test_Types_QValue fails deterministically across all 3 CI matrix configurations with a data mismatch in normalized column values, likely a regression introduced by the recent "fix normalize race" commit touching the Postgres target normalize path. |
❌ Test FailureAnalysis: Test_Types_QValue fails consistently at ~197s across all matrix variants, likely a regression from the recent postgres normalization fix rather than a flaky timeout. |
bc8f275 to
c11670f
Compare
❌ Test FailureAnalysis: TestPeerFlowE2ETestSuitePG/Test_Types_QValue fails consistently across all 3 CI matrix variants at ~197s with the same row mismatch, strongly suggesting a real regression in PG-to-PG normalization likely introduced by the ORDER BY in MERGE change in the latest commit. |
c11670f to
dfb8796
Compare
🔄 Possible Flaky TestAnalysis: Unable to retrieve failure logs as the run is still in progress; low-confidence flaky guess based on the pattern of two sibling matrix jobs (pg16/mysql-gtid, pg18/maria) passing while only the pg17/mysql-pos job is still running. |
🔄 Flaky Test DetectedAnalysis: The e2e test suite failed only in the mysql-pos matrix configuration (768s runtime, near the 900s limit) while identical code passed in maria and mysql-gtid configurations, indicating a timing/infrastructure flake rather than a code regression. ✅ Automatically retrying the workflow |
Note
This feature is only for mirrors with the PG type system
Why
For workloads on source involving very wide tables and data, normalize times for PG to PG mirrors were seen to be considerably high, causing data staleness on target.
Research showed that the ->> JSON access we do for the
_peerdb_datacolumn in our raw table in Postgres is slow.This PR is an optimization we found where instead of having to access every field in
_peerdb_data, we can use jsonb_to_record to first convert the entire JSON value to a row tuple and access its fields, which is much faster.For a 170GB table with 158 columns on Postgres receiving updates, this new MERGE statement was seen to be ~10x faster.
What
client.go, declares a template for a new MERGE statement usingjsonb_to_record.normalize.goto use this new MERGE