mirror of
https://github.com/postgres/postgres.git
synced 2026-04-15 22:10:45 -04:00
28d534e2ae
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
89 lines
3.1 KiB
C
89 lines
3.1 KiB
C
/*-------------------------------------------------------------------------
|
|
*
|
|
* procsignal.h
|
|
* Routines for interprocess signaling
|
|
*
|
|
*
|
|
* Portions Copyright (c) 1996-2026, PostgreSQL Global Development Group
|
|
* Portions Copyright (c) 1994, Regents of the University of California
|
|
*
|
|
* src/include/storage/procsignal.h
|
|
*
|
|
*-------------------------------------------------------------------------
|
|
*/
|
|
#ifndef PROCSIGNAL_H
|
|
#define PROCSIGNAL_H
|
|
|
|
#include "storage/procnumber.h"
|
|
|
|
|
|
/*
|
|
* Reasons for signaling a Postgres child process (a backend or an auxiliary
|
|
* process, like checkpointer). We can cope with concurrent signals for different
|
|
* reasons. However, if the same reason is signaled multiple times in quick
|
|
* succession, the process is likely to observe only one notification of it.
|
|
* This is okay for the present uses.
|
|
*
|
|
* Also, because of race conditions, it's important that all the signals be
|
|
* defined so that no harm is done if a process mistakenly receives one.
|
|
*/
|
|
typedef enum
|
|
{
|
|
PROCSIG_CATCHUP_INTERRUPT, /* sinval catchup interrupt */
|
|
PROCSIG_NOTIFY_INTERRUPT, /* listen/notify interrupt */
|
|
PROCSIG_PARALLEL_MESSAGE, /* message from cooperating parallel backend */
|
|
PROCSIG_WALSND_INIT_STOPPING, /* ask walsenders to prepare for shutdown */
|
|
PROCSIG_BARRIER, /* global barrier interrupt */
|
|
PROCSIG_LOG_MEMORY_CONTEXT, /* ask backend to log the memory contexts */
|
|
PROCSIG_PARALLEL_APPLY_MESSAGE, /* Message from parallel apply workers */
|
|
PROCSIG_REPACK_MESSAGE, /* Message from repack worker */
|
|
PROCSIG_RECOVERY_CONFLICT, /* backend is blocking recovery, check
|
|
* PGPROC->pendingRecoveryConflicts for the
|
|
* reason */
|
|
} ProcSignalReason;
|
|
|
|
#define NUM_PROCSIGNALS (PROCSIG_RECOVERY_CONFLICT + 1)
|
|
|
|
typedef enum
|
|
{
|
|
PROCSIGNAL_BARRIER_SMGRRELEASE, /* ask smgr to close files */
|
|
PROCSIGNAL_BARRIER_UPDATE_XLOG_LOGICAL_INFO, /* ask to update
|
|
* XLogLogicalInfo */
|
|
PROCSIGNAL_BARRIER_CHECKSUM_OFF,
|
|
PROCSIGNAL_BARRIER_CHECKSUM_INPROGRESS_ON,
|
|
PROCSIGNAL_BARRIER_CHECKSUM_INPROGRESS_OFF,
|
|
PROCSIGNAL_BARRIER_CHECKSUM_ON,
|
|
} ProcSignalBarrierType;
|
|
|
|
/*
|
|
* Length of query cancel keys generated.
|
|
*
|
|
* Note that the protocol allows for longer keys, or shorter, but this is the
|
|
* length we actually generate. Client code, and the server code that handles
|
|
* incoming cancellation packets from clients, mustn't use this hardcoded
|
|
* length.
|
|
*/
|
|
#define MAX_CANCEL_KEY_LENGTH 32
|
|
|
|
/*
|
|
* prototypes for functions in procsignal.c
|
|
*/
|
|
extern void ProcSignalInit(const uint8 *cancel_key, int cancel_key_len);
|
|
extern int SendProcSignal(pid_t pid, ProcSignalReason reason,
|
|
ProcNumber procNumber);
|
|
extern void SendCancelRequest(int backendPID, const uint8 *cancel_key, int cancel_key_len);
|
|
|
|
extern uint64 EmitProcSignalBarrier(ProcSignalBarrierType type);
|
|
extern void WaitForProcSignalBarrier(uint64 generation);
|
|
extern void ProcessProcSignalBarrier(void);
|
|
|
|
extern void procsignal_sigusr1_handler(SIGNAL_ARGS);
|
|
|
|
/* ProcSignalHeader is an opaque struct, details known only within procsignal.c */
|
|
typedef struct ProcSignalHeader ProcSignalHeader;
|
|
|
|
#ifdef EXEC_BACKEND
|
|
extern PGDLLIMPORT ProcSignalHeader *ProcSignal;
|
|
#endif
|
|
|
|
#endif /* PROCSIGNAL_H */
|