Debezium 3.7.0.Beta1 Released

Postgres's implicit transactions

PostgreSQL mặc định bọc mỗi câu lệnh trong một giao dịch riêng khi không có BEGIN…COMMIT rõ ràng. Tuy nhiên, khi gửi nhiều câu lệnh trong một chuỗi truy vấn đơn (thông qua PQexec hoặc các hàm plpgsql) hoặc sử dụng các tiện ích như COPY và CREATE INDEX CONCURRENTLY, máy chủ sẽ ẩn ý tạo một giao dịch duy nhất bao gồm tất cả các câu lệnh đó. Điều này có thể dẫn đến việc giữ khóa lâu hơn, tiêu thụ ID giao dịch tăng nhanh và làm khó khăn việc rollback một phần công việc khi lỗi xảy ra. Do đó, lập trình viên cần kiểm tra xem ứng dụng của mình có vô tình nhóm nhiều câu lệnh vào một giao dịch ngầm không và cân nhắc sử dụng BEGIN…COMMIT cụ thể khi cần kiểm soát granularity. Theo dõi pg_stat_activity để phát hiện các giao dịch mở dài hạn cũng là biện pháp phòng ngừa tốt.

Bài này giúp lập trình viên hiểu rõ cách Postgres tự động tạo giao dịch nhiều câu lệnh, tránh lỗi và tối ưu hiệu năng.

pgwatch v6: Prometheus becomes a source, not just a sink

pgwatch là công cụ giám sát PostgreSQL phổ biến, phiên bản 6.0.0-beta vừa ra mắt với nhiều cải tiến về khả năng tích hợp monitoring. Những thay đổi chính là Prometheus hiện nay được cấu hình làm nguồn dữ liệu (source) thay vì chỉ là đích điểm (sink) để pgwatch đẩy metrics qua pushgateway. Điều này cho phép Prometheus tự động thu thập (scrape) metrics từ pgwatch qua HTTP endpoint, giảm độ trễ và loại bỏ nhu cầu cấu hình pushgateway riêng. Kết quả là hệ thống giám sát trở nên đơn giản hơn, độ tin cậy tăng vì giảm một lớp trung gian và dễ dàng mở rộng với các quy tắc cảnh báo của Prometheus. Từ bài học này, các team DevOps có thể suy nghĩ về việc đảo ngược hướng dữ liệu trong các hệ thống quan sát để tối ưu hoá độ trễ và giảm phụ thuộc vào cơ chế push.

Bài viết này giúp lập trình viên hiểu cách Prometheus trong pgwatch v6 chuyển từ điểm thu thập dữ liệu thành nguồn cung cấp dữ liệu, mang lại khả năng giám sát và phân tích hiệu suất cơ sở dữ liệu Postgres linh hoạt hơn.

All Your GUCs in a Row: log_destination and logging_collector

Bài viết giải thích vai trò của hai tham số GUC log_destination và logging_collector trong PostgreSQL, mô tả cách logging collector hoạt động như một daemon dựa trên pipe để tránh mất và garbled log messages. Khi bật logging_collector, PostgreSQL phải khởi động lại vì daemon được tạo trong quá trình khởi động, và các định dạng log như stderr, csvlog và jsonlog đều được đưa vào pipe này. Tuy nhiên, dưới tải cao, collector có thể trở thành điểm nghẽn và làm giãn cả instance, trong khi việc sử dụng syslog lại có nguy cơ silently drop messages khi hệ thống quá tải. Bài cũng so sánh mặc định của log_destination trên các nền tảng phổ biến: Debian/Ubuntu thường để stderr, PGDG RPMs thường dùng csvlog, Docker images và một số dịch vụ quản lý có thể pre‑configure jsonlog hoặc syslog tùy theo nhà cung cấp. Từ đó, tác giả khuyên trong môi trường production nên chọn định dạng log phù hợp với hệ thống giám sát, bật logging_collector chỉ khi cần lưu trữ tập trung và luôn monitor throughput để tránh stall, đồng thời cân nhắc sử dụng syslog với buffer đủ lớn hoặc các giải pháp bên ngoài như Fluentd để tránh mất log.

Bài giải thích chi tiết về log_destination và logging_collector GUCs giúp bạn hiểu rõ cơ chế logging của PostgreSQL, từ đó tối ưu hóa cấu hình giám sát và xử lý log hiệu quả trong môi trường production.

WAL + S3: Lakebase storage for the era of agents

Bài viết mô tả bối cảnh nhu cầu tách biệt lưu trữ và tính toán trong hệ thống Postgres khi ứng dụng AI agents ngày càng tăng. Nó giải thích cách coi WAL (Write‑Ahead Log) như nguồn thực thể duy nhất và đưa nó lên Amazon S3 để lưu trữ đối tượng. Kỹ thuật này cho phép ricostruzione cơ sở dữ liệu từ WAL trên S3 mà không cần giữ toàn bộ dữ liệu trên đĩa local, giảm chi phí lưu trữ và mở rộng khả năng sao chép bất đồng bộ. Các tác động bao gồm thời gian phục hồi nhanh hơn, khả năng truy vấn lịch sử dữ liệu trực tiếp từ S3 và tích hợp dễ dàng với các công cụ xử lý sự kiện cho agents. Bài học chính là việc xem WAL như lớp lưu trữ không thay đổi mở ra kiến trúc lakebase, giúp团队 tách biệt công việc vận hành Postgres khỏi chi phí cơ sở hạ tầng và chuẩn bị sẵn sàng cho workloads AI‑native.

Bài viết giúp lập trình viên hiểu cách tận dụng WAL và S3 để tối ưu hóa lưu trữ dữ liệu trong thời đại AI agents.

Connection Pool Sizing, Measured: Why 48 Connections Beat 400

Bài viết thực nghiệm trên PostgreSQL bằng cách tăng số kết nối từ 1 lên 400 để đo …

LibreDB Studio: an open source, self-hosted SQL IDE for PostgreSQL in the browser

LibreDB Studio là IDE SQL mã nguồn mở, tự host cho PostgreSQL chạy trên trình duyệt, triển …

The Sixth Execution

PostgreSQL chuẩn bị câu lệnh (prepared statement) sẽ tạo kế hoạch tùy chỉnh dựa trên giá trị tham số thực tế trong năm lần thực thi đầu tiên, mang lại chất lượng kế hoạch như thay thế văn bản. Khi đến lần thực thi thứ sáu, hệ thống xây dựng kế hoạch chung (generic plan) không sử dụng giá trị tham số và so sánh chi phí ước tính của nó với chi phí trung bình của các kế hoạch tùy chỉnh; nếu kế hoạch chung có chi phí thấp hơn, PostgreSQL sẽ chuyển sang dùng kế hoạch chung và giữ nó cho tới khi bị làm vô hiệu. Kế hoạch chung dựa trên ước tính chọn lọc mù quáng (ví dụ, phân số không null chia số giá trị riêng biệt cho phép bằng, một phần ba bảng cho phép không bằng), có thể sai lệch nghiêm trọng trên dữ liệu lệch, dẫn đến việc truy vấn chậm xuống bất ngờ sau lần thực thi thứ sáu. Quyết định này chỉ dựa trên chi phí ước tính, không đo lường thời gian thực thi thực và có tính dính dáng bất đối xứng; các nguyên nhân thường gặp là hàm PL/pgSQL và các driver như psycopg 3 hoặc JDBC mà tự động nâng cấp thành câu lệnh có tên sau ngưỡng mặc định (5 lần), khiến chuyển đổi xảy ra khoảng lần thực thi thứ mười hoặc mười một. Các biện pháp khắc phục bao gồm đặt plan_cache_mode=force_custom_plan cho các truy vấn lệch, tắt chuẩn bị ở mức driver (prepare=False), viết lại truy vấn hoặc tạo chỉ mục phần phần trên cột lệch.

Bài này giúp lập trình viên hiểu và giải quyết hiện tượng truy vấn PostgreSQL đột ngột chậm sau lần thực hiện thứ sáu do sự chuyển đổi sang generic plan không phù hợp với dữ liệu không đồng nhất.

MySQL CPU and CSPU Versioning for More Frequent Security Updates

MySQL đã đưa ra hai kênh bản vá bảo mật khác nhau: CPU (Critical Patch Update) và CSPU (Cumulative Security Patch Update). Các bản CPU được phát hành ngoài chuỗi bản vá thường xuyên để khắc phục ngay các lỗ hổng nghiêm trọng, trong khi CSPU tích hợp những bản vá này vào các cập nhật định kỳ. Việc tách riêng cho phép người dùng áp dụng các bản vá bảo mật nhanh chóng mà không phải chờ đợi phiên bản lớn tiếp theo. Nhờ đó, khoảng thời gian giữa việc phát hiện lỗ hổng và việc vá lỗi được giảm đáng kể. Kinh nghiệm này cho thấy việc phân luân bản vá bảo mậtCritical và bản vá tích hợp có thể nâng cao tần suất và hiệu quả của quá trình cập nhật bảo mật.

Bài viết giúp lập trình viên hiểu rõ cách hệ thống phiên bản MySQL mới hỗ trợ cập nhật bảo mật thường xuyên hơn thông qua mô hình CPU và CSPU.