postgres-github.git / summary / log / commit / refs

commit    28d534e2ae0ac888b5460f977a10cd9bb017ef98
Author:   Álvaro Herrera <alvherre@kurilemu.de>
Date:     Mon Apr 06 19:55:08 2026 +0000

    Add CONCURRENTLY option to REPACK
    
    When this flag is specified, REPACK no longer acquires access-exclusive
    lock while the new copy of the table is being created; instead, it
    creates the initial copy under share-update-exclusive lock only (same as
    vacuum, etc), and it follows an MVCC snapshot; it sets up a replication
    slot starting at that snapshot, and uses a concurrent background worker
    to do logical decoding starting at the snapshot to populate a stash of
    concurrent data changes.  Those changes can then be re-applied to the
    new copy of the table just before swapping the relfilenodes.
    Applications can continue to access the original copy of the table
    normally until just before the swap, which is the only point at which
    the access-exclusive lock is needed.
    
    There are some loose ends in this commit:
    1. concurrent repack needs its own replication slot in order to apply
       logical decoding, which are a scarce resource and easy to run out of.
    2. due to the way the historic snapshot is initially set up, only one
       REPACK process can be running at any one time on the whole system.
    3. there's a danger of deadlocking (and thus abort) due to the lock
       upgrade required at the final phase.
    
    These issues will be addressed in upcoming commits.
    
    The design and most of the code are by Antonin Houska, heavily based on
    his own pg_squeeze third-party implementation.
    
    Author: Antonin Houska <ah@cybertec.at>
    Co-authored-by: Mihail Nikalayeu <mihailnikalayeu@gmail.com>
    Co-authored-by: Álvaro Herrera <alvherre@kurilemu.de>
    Reviewed-by: Matthias van de Meent <boekewurm+postgres@gmail.com>
    Reviewed-by: Srinath Reddy Sadipiralla <srinath2133@gmail.com>
    Reviewed-by: Amit Kapila <amit.kapila16@gmail.com>
    Reviewed-by: Jim Jones <jim.jones@uni-muenster.de>
    Reviewed-by: Robert Treat <rob@xzilla.net>
    Reviewed-by: Noriyoshi Shinoda <noriyoshi.shinoda@hpe.com>
    Reviewed-by: vignesh C <vignesh21@gmail.com>
    Discussion: https://postgr.es/m/5186.1706694913@antos
    Discussion: https://postgr.es/m/202507262156.sb455angijk6@alvherre.pgsql

[parent: 10484c2cc75b]