Relational Databases

  Pg_verifybackup was introduced in PostgreSQL 13 and is used to check the integrity of a base backup taken using Pg_basebackup against the backup_manifest file generated by the server. The manifest is a JSON document containing information about the backup files, including their paths, sizes, last modification times, and, optionally, checksums. For example: { "PostgreSQL-Backup-Manifest-Version" : 2 , "System-Identifier" : 7694938432524117566 , "Files" : [ { "Path" : "backup_label" , "Size" : 227 , "Last-Modified" : "2026-10-10 07:42:44 GMT" , "Checksum-Algorithm" : "CRC32C" , "Checksum" : "509e2e33" } , { "Path" : "global/1262" , "Size" : 8192 , "Last-Modified" : "2026-10-10 07:35:34 GMT" , "Checksum-Algorithm" : "CRC32C" , "Checksum" : "d7e25e67" } , ...

  For years, PostgreSQL DBAs have relied on VACUUM FULL to rewrite tables and reclaim unused space. However, when minimizing the impact of table reorganization is important, tools such as pg_repack provide an online-style alternative. PostgreSQL 19 introduces the new REPACK command as a built-in solution for table reorganization, including REPACK CONCURRENTLY , which allows the table to remain available for normal database activity during most of the operation. PostgreSQL 19 also extends this capability with support for reorganizing a table according to an index, providing functionality comparable to the physical ordering achieved with CLUSTER . How REPACK Works REPACK does not simply compact the existing table in place. Conceptually, it creates a new, compact copy of the table, copies the existing rows into it, tracks changes made to the original table while the operation is running, and applies those changes to the new table. At the end, it performs a short final synchronizat...