my-ship-it commented on issue #1545: URL: https://github.com/apache/cloudberry/issues/1545#issuecomment-4140293490
Hi @wangyong86, Thanks for this excellent bug report! Your analysis is really thorough and insightful — especially the comparison between how COPY and SELECT handle snapshots, and the deep dive into the MVCC visibility logic in CBDB vs PostgreSQL. 👏 To summarize the issue: - `COPY TO` acquires its snapshot **before** taking the lock on the table, and never refreshes it afterward. So when `ALTER TABLE ... SET WITH (reorganize=true)` rewrites the table concurrently, the new tuples' `xid >= snapshot->xmax`, making them invisible to COPY — resulting in 0 rows. - `SELECT` doesn't have this problem because it refreshes the snapshot **after** acquiring the lock. - In PostgreSQL, `VACUUM FULL` produces data-frozen tuples that are always visible regardless of snapshot timing, avoiding this issue entirely. The great news is that this has been fixed in PR #1605 (merged on March 9, 2026) by @gfphoenix78. The fix addresses the snapshot/lock ordering problem across three code paths: 1. **Relation-based COPY TO** — refreshes the snapshot after acquiring `AccessShareLock`. 2. **Query-based COPY TO / RLS / CTAS** — refreshes the snapshot after `AcquireRewriteLocks()`. 3. **Partitioned table COPY TO** — eagerly locks all child partitions before the snapshot is taken. The fix will be available in the next release. Thanks again for the detailed report and analysis — it really helped drive a solid fix! 🙏 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
