标签：#isolation

Short answer: use automated background removal for volume, then reserve manual crops for images where a wrong edge costs more than the bandwidth and review time. The useful design is a queue with a confidence gate, not a permanent argument over which tool is “best.” How Should Catalog Teams Balance Background Removal and Manual Crop? Catalog isolation sounds like a visual task. In a SaaS catalog, it is a data pipeline. A seller uploads a product photo, the service produces an isolated asset, and every downstream surface expects the subject to stay inside a predictable box. Quality and bandwidth pull in opposite directions: a high-resolution source preserves fine edges but costs more to move and process; an aggressive resize is quick but can erase the exact detail the mask needs. The decision therefore belongs in a policy that engineering, catalog operations, and support can inspect. Give that policy named outcomes such as auto , manual , and needs_source ; attach the crop rectangle and confidence to each result; and retain enough input metadata to reproduce the decision. Without those records, a quality complaint becomes a debate over screenshots. With them, the team can compare the received file, preview dimensions, mask, final derivative, and policy version in order. Start with an explicit decision table. It gives support and operations one shared vocabulary when an image lands in the review queue. Input or business signal Default path Why Reconsider when Clean background, centered object, thousands of SKUs Automated removal at a bounded preview size Fast throughput and consistent framing Hair, glass, or transparent parts dominate the silhouette Irregular edges or a high-value hero image Manual crop and edge review A person can preserve meaningful contours The review queue becomes the release bottleneck Uncertain subject or cluttered scene Keep the original and request a better photo Prevents a confident-looking bad cutout The seller can supply a controlled backdr

Read Committed: snapshot mỗi statement, và vì sao hai SELECT trong cùng transaction có thể trả khác nhau READ COMMITTED là isolation level mặc định của PostgreSQL, và là level mà phần lớn workload OLTP đang chạy mà không biết. Khác với mô hình "transaction lấy một snapshot rồi giữ nguyên" mà nhiều dev tưởng tượng từ MVCC, ở Read Committed mỗi statement lấy một snapshot mới tại thời điểm statement bắt đầu , không phải tại thời điểm BEGIN . Hậu quả thực tế: hai SELECT liên tiếp trong cùng một transaction có thể trả về dữ liệu khác nhau nếu giữa hai lần đó có transaction khác commit. Đây là non-repeatable read — đúng spec của Read Committed, không phải bug — và là nguồn của một class lỗi rất hay gặp: code đọc một giá trị, ra quyết định, rồi cập nhật dựa trên giá trị đã đọc, trong khi giá trị thực tế đã thay đổi. Cơ chế hoạt động Một transaction ở Read Committed không có transaction-level snapshot . Khi mỗi statement (mỗi SELECT , UPDATE , DELETE , INSERT ... SELECT ...) bắt đầu thực thi, backend lấy một snapshot mới gồm xmin , xmax và xip list — chính cái snapshot quyết định row version nào "visible" theo MVCC. Statement chỉ thấy: row có xmin đã commit trước thời điểm statement bắt đầu , và xmax chưa tồn tại hoặc thuộc một transaction chưa commit / đã abort. Ngay sau khi statement kết thúc, snapshot đó bị bỏ. Statement kế tiếp lấy snapshot mới — nếu trong khoảng giữa có transaction khác commit, statement này sẽ thấy dữ liệu mới đó. -- T1 BEGIN ; -- KHÔNG lấy snapshot ở đây SELECT balance FROM accounts WHERE id = 1 ; -- snapshot S1 -> trả 1000 -- ... T2 chạy: UPDATE accounts SET balance=500 WHERE id=1; COMMIT; SELECT balance FROM accounts WHERE id = 1 ; -- snapshot S2 -> trả 500 COMMIT ; Với UPDATE / DELETE / SELECT ... FOR UPDATE / FOR NO KEY UPDATE / FOR SHARE , Read Committed làm thêm một bước đặc biệt mà SELECT thường không làm: nếu target row bị một transaction khác đang lock (chưa commit), statement đợi transaction đó kết thúc. Khi unblock: nếu transaction kia ROL