agora inbox for [email protected]help / color / mirror / Atom feed
[PATCH v49 3/7] Make archiver process an auxiliary process 29+ messages / 12 participants [nested] [flat]
* [PATCH v49 3/7] Make archiver process an auxiliary process @ 2020-03-13 07:59 Kyotaro Horiguchi <[email protected]> 0 siblings, 0 replies; 29+ messages in thread From: Kyotaro Horiguchi @ 2020-03-13 07:59 UTC (permalink / raw) This is a preliminary patch for shared-memory based stats collector. Archiver process must be a auxiliary process since it uses shared memory after stats data was moved into shared-memory. Make the process an auxiliary process in order to make it work. --- src/backend/access/transam/xlogarchive.c | 7 +- src/backend/bootstrap/bootstrap.c | 22 +-- src/backend/postmaster/pgarch.c | 174 +++-------------------- src/backend/postmaster/postmaster.c | 88 ++++++------ src/backend/storage/lmgr/proc.c | 1 + src/include/miscadmin.h | 2 + src/include/postmaster/pgarch.h | 10 +- src/include/storage/pmsignal.h | 1 - src/include/storage/proc.h | 10 +- 9 files changed, 83 insertions(+), 232 deletions(-) diff --git a/src/backend/access/transam/xlogarchive.c b/src/backend/access/transam/xlogarchive.c index 1c5a4f8b5a..8b66a30931 100644 --- a/src/backend/access/transam/xlogarchive.c +++ b/src/backend/access/transam/xlogarchive.c @@ -29,7 +29,8 @@ #include "storage/fd.h" #include "storage/ipc.h" #include "storage/lwlock.h" -#include "storage/pmsignal.h" +#include "storage/latch.h" +#include "storage/proc.h" /* * Attempt to retrieve the specified file from off-line archival storage. @@ -490,8 +491,8 @@ XLogArchiveNotify(const char *xlog) } /* Notify archiver that it's got something to do */ - if (IsUnderPostmaster) - SendPostmasterSignal(PMSIGNAL_WAKEN_ARCHIVER); + if (IsUnderPostmaster && ProcGlobal->archiverLatch) + SetLatch(ProcGlobal->archiverLatch); } /* diff --git a/src/backend/bootstrap/bootstrap.c b/src/backend/bootstrap/bootstrap.c index 6f615e6622..41da0c5059 100644 --- a/src/backend/bootstrap/bootstrap.c +++ b/src/backend/bootstrap/bootstrap.c @@ -317,6 +317,9 @@ AuxiliaryProcessMain(int argc, char *argv[]) case StartupProcess: MyBackendType = B_STARTUP; break; + case ArchiverProcess: + MyBackendType = B_ARCHIVER; + break; case BgWriterProcess: MyBackendType = B_BG_WRITER; break; @@ -437,30 +440,29 @@ AuxiliaryProcessMain(int argc, char *argv[]) proc_exit(1); /* should never return */ case StartupProcess: - /* don't set signals, startup process has its own agenda */ StartupProcessMain(); - proc_exit(1); /* should never return */ + proc_exit(1); + + case ArchiverProcess: + PgArchiverMain(); + proc_exit(1); case BgWriterProcess: - /* don't set signals, bgwriter has its own agenda */ BackgroundWriterMain(); - proc_exit(1); /* should never return */ + proc_exit(1); case CheckpointerProcess: - /* don't set signals, checkpointer has its own agenda */ CheckpointerMain(); - proc_exit(1); /* should never return */ + proc_exit(1); case WalWriterProcess: - /* don't set signals, walwriter has its own agenda */ InitXLOGAccess(); WalWriterMain(); - proc_exit(1); /* should never return */ + proc_exit(1); case WalReceiverProcess: - /* don't set signals, walreceiver has its own agenda */ WalReceiverMain(); - proc_exit(1); /* should never return */ + proc_exit(1); default: elog(PANIC, "unrecognized process type: %d", (int) MyAuxProcType); diff --git a/src/backend/postmaster/pgarch.c b/src/backend/postmaster/pgarch.c index edec311f12..e237cedaff 100644 --- a/src/backend/postmaster/pgarch.c +++ b/src/backend/postmaster/pgarch.c @@ -48,6 +48,7 @@ #include "storage/latch.h" #include "storage/pg_shmem.h" #include "storage/pmsignal.h" +#include "storage/procsignal.h" #include "utils/guc.h" #include "utils/ps_status.h" @@ -78,25 +79,17 @@ * Local data * ---------- */ -static time_t last_pgarch_start_time; static time_t last_sigterm_time = 0; /* * Flags set by interrupt handlers for later service in the main loop. */ -static volatile sig_atomic_t wakened = false; static volatile sig_atomic_t ready_to_stop = false; /* ---------- * Local function forward declarations * ---------- */ -#ifdef EXEC_BACKEND -static pid_t pgarch_forkexec(void); -#endif - -NON_EXEC_STATIC void PgArchiverMain(int argc, char *argv[]) pg_attribute_noreturn(); -static void pgarch_waken(SIGNAL_ARGS); static void pgarch_waken_stop(SIGNAL_ARGS); static void pgarch_MainLoop(void); static void pgarch_ArchiverCopyLoop(void); @@ -105,121 +98,9 @@ static bool pgarch_readyXlog(char *xlog); static void pgarch_archiveDone(char *xlog); -/* ------------------------------------------------------------ - * Public functions called from postmaster follow - * ------------------------------------------------------------ - */ - -/* - * pgarch_start - * - * Called from postmaster at startup or after an existing archiver - * died. Attempt to fire up a fresh archiver process. - * - * Returns PID of child process, or 0 if fail. - * - * Note: if fail, we will be called again from the postmaster main loop. - */ -int -pgarch_start(void) -{ - time_t curtime; - pid_t pgArchPid; - - /* - * Do nothing if no archiver needed - */ - if (!XLogArchivingActive()) - return 0; - - /* - * Do nothing if too soon since last archiver start. This is a safety - * valve to protect against continuous respawn attempts if the archiver is - * dying immediately at launch. Note that since we will be re-called from - * the postmaster main loop, we will get another chance later. - */ - curtime = time(NULL); - if ((unsigned int) (curtime - last_pgarch_start_time) < - (unsigned int) PGARCH_RESTART_INTERVAL) - return 0; - last_pgarch_start_time = curtime; - -#ifdef EXEC_BACKEND - switch ((pgArchPid = pgarch_forkexec())) -#else - switch ((pgArchPid = fork_process())) -#endif - { - case -1: - ereport(LOG, - (errmsg("could not fork archiver: %m"))); - return 0; - -#ifndef EXEC_BACKEND - case 0: - /* in postmaster child ... */ - InitPostmasterChild(); - - /* Close the postmaster's sockets */ - ClosePostmasterPorts(false); - - /* Drop our connection to postmaster's shared memory, as well */ - dsm_detach_all(); - PGSharedMemoryDetach(); - - PgArchiverMain(0, NULL); - break; -#endif - - default: - return (int) pgArchPid; - } - - /* shouldn't get here */ - return 0; -} - -/* ------------------------------------------------------------ - * Local functions called by archiver follow - * ------------------------------------------------------------ - */ - - -#ifdef EXEC_BACKEND - -/* - * pgarch_forkexec() - - * - * Format up the arglist for, then fork and exec, archive process - */ -static pid_t -pgarch_forkexec(void) -{ - char *av[10]; - int ac = 0; - - av[ac++] = "postgres"; - - av[ac++] = "--forkarch"; - - av[ac++] = NULL; /* filled in by postmaster_forkexec */ - - av[ac] = NULL; - Assert(ac < lengthof(av)); - - return postmaster_forkexec(ac, av); -} -#endif /* EXEC_BACKEND */ - - -/* - * PgArchiverMain - * - * The argc/argv parameters are valid only in EXEC_BACKEND case. However, - * since we don't use 'em, it hardly matters... - */ -NON_EXEC_STATIC void -PgArchiverMain(int argc, char *argv[]) +/* Main entry point for archiver process */ +void +PgArchiverMain(void) { /* * Ignore all signals usually bound to some action in the postmaster, @@ -231,31 +112,24 @@ PgArchiverMain(int argc, char *argv[]) /* SIGQUIT handler was already set up by InitPostmasterChild */ pqsignal(SIGALRM, SIG_IGN); pqsignal(SIGPIPE, SIG_IGN); - pqsignal(SIGUSR1, pgarch_waken); + pqsignal(SIGUSR1, procsignal_sigusr1_handler); pqsignal(SIGUSR2, pgarch_waken_stop); + /* Reset some signals that are accepted by postmaster but not here */ pqsignal(SIGCHLD, SIG_DFL); + + /* Unblock signals (they were blocked when the postmaster forked us) */ PG_SETMASK(&UnBlockSig); - MyBackendType = B_ARCHIVER; - init_ps_display(NULL); + /* + * Advertise our latch that backends can use to wake us up while we're + * sleeping. + */ + ProcGlobal->archiverLatch = &MyProc->procLatch; pgarch_MainLoop(); - exit(0); -} - -/* SIGUSR1 signal handler for archiver process */ -static void -pgarch_waken(SIGNAL_ARGS) -{ - int save_errno = errno; - - /* set flag that there is work to be done */ - wakened = true; - SetLatch(MyLatch); - - errno = save_errno; + proc_exit(0); } /* SIGUSR2 signal handler for archiver process */ @@ -282,14 +156,6 @@ pgarch_MainLoop(void) pg_time_t last_copy_time = 0; bool time_to_stop; - /* - * We run the copy loop immediately upon entry, in case there are - * unarchived files left over from a previous database run (or maybe the - * archiver died unexpectedly). After that we wait for a signal or - * timeout before doing more. - */ - wakened = true; - /* * There shouldn't be anything for the archiver to do except to wait for a * signal ... however, the archiver exists to protect our data, so she @@ -328,12 +194,8 @@ pgarch_MainLoop(void) } /* Do what we're here for */ - if (wakened || time_to_stop) - { - wakened = false; - pgarch_ArchiverCopyLoop(); - last_copy_time = time(NULL); - } + pgarch_ArchiverCopyLoop(); + last_copy_time = time(NULL); /* * Sleep until a signal is received, or until a poll is forced by @@ -354,13 +216,9 @@ pgarch_MainLoop(void) WL_LATCH_SET | WL_TIMEOUT | WL_POSTMASTER_DEATH, timeout * 1000L, WAIT_EVENT_ARCHIVER_MAIN); - if (rc & WL_TIMEOUT) - wakened = true; if (rc & WL_POSTMASTER_DEATH) time_to_stop = true; } - else - wakened = true; } /* diff --git a/src/backend/postmaster/postmaster.c b/src/backend/postmaster/postmaster.c index edab95a19e..d9f8d82650 100644 --- a/src/backend/postmaster/postmaster.c +++ b/src/backend/postmaster/postmaster.c @@ -548,6 +548,7 @@ static void ShmemBackendArrayRemove(Backend *bn); #endif /* EXEC_BACKEND */ #define StartupDataBase() StartChildProcess(StartupProcess) +#define StartArchiver() StartChildProcess(ArchiverProcess) #define StartBackgroundWriter() StartChildProcess(BgWriterProcess) #define StartCheckpointer() StartChildProcess(CheckpointerProcess) #define StartWalWriter() StartChildProcess(WalWriterProcess) @@ -1792,7 +1793,7 @@ ServerLoop(void) /* If we have lost the archiver, try to start a new one. */ if (PgArchPID == 0 && PgArchStartupAllowed()) - PgArchPID = pgarch_start(); + PgArchPID = StartArchiver(); /* If we need to signal the autovacuum launcher, do so now */ if (avlauncher_needs_signal) @@ -3007,7 +3008,7 @@ reaper(SIGNAL_ARGS) if (!IsBinaryUpgrade && AutoVacuumingActive() && AutoVacPID == 0) AutoVacPID = StartAutoVacLauncher(); if (PgArchStartupAllowed() && PgArchPID == 0) - PgArchPID = pgarch_start(); + PgArchPID = StartArchiver(); if (PgStatPID == 0) PgStatPID = pgstat_start(); @@ -3126,6 +3127,18 @@ reaper(SIGNAL_ARGS) continue; } + /* + * Was it the archiver? We treat it the same way to WAL receiver. + */ + if (pid == PgArchPID) + { + PgArchPID = 0; + if (!EXIT_STATUS_0(exitstatus) && !EXIT_STATUS_1(exitstatus)) + HandleChildCrash(pid, exitstatus, + _("archiver process")); + continue; + } + /* * Was it the autovacuum launcher? Normal exit can be ignored; we'll * start a new one at the next iteration of the postmaster's main @@ -3141,24 +3154,6 @@ reaper(SIGNAL_ARGS) continue; } - /* - * Was it the archiver? If so, just try to start a new one; no need - * to force reset of the rest of the system. (If fail, we'll try - * again in future cycles of the main loop.). Unless we were waiting - * for it to shut down; don't restart it in that case, and - * PostmasterStateMachine() will advance to the next shutdown step. - */ - if (pid == PgArchPID) - { - PgArchPID = 0; - if (!EXIT_STATUS_0(exitstatus)) - LogChildExit(LOG, _("archiver process"), - pid, exitstatus); - if (PgArchStartupAllowed()) - PgArchPID = pgarch_start(); - continue; - } - /* * Was it the statistics collector? If so, just try to start a new * one; no need to force reset of the rest of the system. (If fail, @@ -3403,7 +3398,7 @@ CleanupBackend(int pid, /* * HandleChildCrash -- cleanup after failed backend, bgwriter, checkpointer, - * walwriter, autovacuum, or background worker. + * walwriter, autovacuum, archiver or background worker. * * The objectives here are to clean up our local state about the child * process, and to signal all other remaining children to quickdie. @@ -3609,19 +3604,16 @@ HandleChildCrash(int pid, int exitstatus, const char *procname) signal_child(AutoVacPID, (SendStop ? SIGSTOP : SIGQUIT)); } - /* - * Force a power-cycle of the pgarch process too. (This isn't absolutely - * necessary, but it seems like a good idea for robustness, and it - * simplifies the state-machine logic in the case where a shutdown request - * arrives during crash processing.) - */ - if (PgArchPID != 0 && take_action) + /* Take care of the archiver too */ + if (pid == PgArchPID) + PgArchPID = 0; + else if (PgArchPID != 0 && take_action) { ereport(DEBUG2, (errmsg_internal("sending %s to process %d", - "SIGQUIT", + (SendStop ? "SIGSTOP" : "SIGQUIT"), (int) PgArchPID))); - signal_child(PgArchPID, SIGQUIT); + signal_child(PgArchPID, (SendStop ? SIGSTOP : SIGQUIT)); } /* @@ -3912,6 +3904,7 @@ PostmasterStateMachine(void) Assert(CheckpointerPID == 0); Assert(WalWriterPID == 0); Assert(AutoVacPID == 0); + Assert(PgArchPID == 0); /* syslogger is not considered here */ pmState = PM_NO_CHILDREN; } @@ -4989,6 +4982,19 @@ SubPostmasterMain(int argc, char *argv[]) AuxiliaryProcessMain(argc - 2, argv + 2); /* does not return */ } + if (strcmp(argv[1], "--forkarch") == 0) + { + /* Restore basic shared memory pointers */ + InitShmemAccess(UsedShmemSegAddr); + + /* Need a PGPROC to run CreateSharedMemoryAndSemaphores */ + InitAuxiliaryProcess(); + + /* Attach process to shared data structures */ + CreateSharedMemoryAndSemaphores(); + + PgArchiverMain(); /* does not return */ + } if (strcmp(argv[1], "--forkavlauncher") == 0) { /* Restore basic shared memory pointers */ @@ -5037,12 +5043,6 @@ SubPostmasterMain(int argc, char *argv[]) StartBackgroundWorker(); } - if (strcmp(argv[1], "--forkarch") == 0) - { - /* Do not want to attach to shared memory */ - - PgArchiverMain(argc, argv); /* does not return */ - } if (strcmp(argv[1], "--forkcol") == 0) { /* Do not want to attach to shared memory */ @@ -5140,7 +5140,7 @@ sigusr1_handler(SIGNAL_ARGS) */ Assert(PgArchPID == 0); if (XLogArchivingAlways()) - PgArchPID = pgarch_start(); + PgArchPID = StartArchiver(); /* * If we aren't planning to enter hot standby mode later, treat @@ -5194,16 +5194,6 @@ sigusr1_handler(SIGNAL_ARGS) if (StartWorkerNeeded || HaveCrashedWorker) maybe_start_bgworkers(); - if (CheckPostmasterSignal(PMSIGNAL_WAKEN_ARCHIVER) && - PgArchPID != 0) - { - /* - * Send SIGUSR1 to archiver process, to wake it up and begin archiving - * next WAL file. - */ - signal_child(PgArchPID, SIGUSR1); - } - /* Tell syslogger to rotate logfile if requested */ if (SysLoggerPID != 0) { @@ -5445,6 +5435,10 @@ StartChildProcess(AuxProcType type) ereport(LOG, (errmsg("could not fork startup process: %m"))); break; + case ArchiverProcess: + ereport(LOG, + (errmsg("could not fork archiver process: %m"))); + break; case BgWriterProcess: ereport(LOG, (errmsg("could not fork background writer process: %m"))); diff --git a/src/backend/storage/lmgr/proc.c b/src/backend/storage/lmgr/proc.c index 897045ee27..bf5d6da89b 100644 --- a/src/backend/storage/lmgr/proc.c +++ b/src/backend/storage/lmgr/proc.c @@ -182,6 +182,7 @@ InitProcGlobal(void) ProcGlobal->startupBufferPinWaitBufId = -1; ProcGlobal->walwriterLatch = NULL; ProcGlobal->checkpointerLatch = NULL; + ProcGlobal->archiverLatch = NULL; pg_atomic_init_u32(&ProcGlobal->procArrayGroupFirst, INVALID_PGPROCNO); pg_atomic_init_u32(&ProcGlobal->clogGroupFirst, INVALID_PGPROCNO); diff --git a/src/include/miscadmin.h b/src/include/miscadmin.h index 1bdc97e308..adb9f819bb 100644 --- a/src/include/miscadmin.h +++ b/src/include/miscadmin.h @@ -419,6 +419,7 @@ typedef enum BootstrapProcess, StartupProcess, BgWriterProcess, + ArchiverProcess, CheckpointerProcess, WalWriterProcess, WalReceiverProcess, @@ -431,6 +432,7 @@ extern AuxProcType MyAuxProcType; #define AmBootstrapProcess() (MyAuxProcType == BootstrapProcess) #define AmStartupProcess() (MyAuxProcType == StartupProcess) #define AmBackgroundWriterProcess() (MyAuxProcType == BgWriterProcess) +#define AmArchiverProcess() (MyAuxProcType == ArchiverProcess) #define AmCheckpointerProcess() (MyAuxProcType == CheckpointerProcess) #define AmWalWriterProcess() (MyAuxProcType == WalWriterProcess) #define AmWalReceiverProcess() (MyAuxProcType == WalReceiverProcess) diff --git a/src/include/postmaster/pgarch.h b/src/include/postmaster/pgarch.h index d102a21ab7..737ed69e57 100644 --- a/src/include/postmaster/pgarch.h +++ b/src/include/postmaster/pgarch.h @@ -26,14 +26,6 @@ #define MAX_XFN_CHARS 40 #define VALID_XFN_CHARS "0123456789ABCDEF.history.backup.partial" -/* ---------- - * Functions called from postmaster - * ---------- - */ -extern int pgarch_start(void); - -#ifdef EXEC_BACKEND -extern void PgArchiverMain(int argc, char *argv[]) pg_attribute_noreturn(); -#endif +extern void PgArchiverMain(void) pg_attribute_noreturn(); #endif /* _PGARCH_H */ diff --git a/src/include/storage/pmsignal.h b/src/include/storage/pmsignal.h index dbbed18f61..8ed4d87ae6 100644 --- a/src/include/storage/pmsignal.h +++ b/src/include/storage/pmsignal.h @@ -34,7 +34,6 @@ typedef enum { PMSIGNAL_RECOVERY_STARTED, /* recovery has started */ PMSIGNAL_BEGIN_HOT_STANDBY, /* begin Hot Standby */ - PMSIGNAL_WAKEN_ARCHIVER, /* send a NOTIFY signal to xlog archiver */ PMSIGNAL_ROTATE_LOGFILE, /* send SIGUSR1 to syslogger to rotate logfile */ PMSIGNAL_START_AUTOVAC_LAUNCHER, /* start an autovacuum launcher */ PMSIGNAL_START_AUTOVAC_WORKER, /* start an autovacuum worker */ diff --git a/src/include/storage/proc.h b/src/include/storage/proc.h index a777cb64a1..d73890b228 100644 --- a/src/include/storage/proc.h +++ b/src/include/storage/proc.h @@ -357,6 +357,8 @@ typedef struct PROC_HDR int startupProcPid; /* Buffer id of the buffer that Startup process waits for pin on, or -1 */ int startupBufferPinWaitBufId; + /* Archiver process's latch */ + Latch *archiverLatch; } PROC_HDR; extern PGDLLIMPORT PROC_HDR *ProcGlobal; @@ -370,11 +372,11 @@ extern PGPROC *PreparedXactProcs; * We set aside some extra PGPROC structures for auxiliary processes, * ie things that aren't full-fledged backends but need shmem access. * - * Background writer, checkpointer and WAL writer run during normal operation. - * Startup process and WAL receiver also consume 2 slots, but WAL writer is - * launched only after startup has exited, so we only need 4 slots. + * Background writer, checkpointer, WAL writer and archiver run during normal + * operation. Startup process and WAL receiver also consume 2 slots, but WAL + * writer is launched only after startup has exited, so we only need 5 slots. */ -#define NUM_AUXILIARY_PROCS 4 +#define NUM_AUXILIARY_PROCS 5 /* configurable options */ extern PGDLLIMPORT int DeadlockTimeout; -- 2.27.0 ----Next_Part(Tue_Mar__9_16_53_11_2021_575)-- Content-Type: Text/X-Patch; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="v49-0004-Shared-memory-based-stats-collector.patch" ^ permalink raw reply [nested|flat] 29+ messages in thread
* Commit fest 2022-11 @ 2022-10-31 05:42 Michael Paquier <[email protected]> 0 siblings, 2 replies; 29+ messages in thread From: Michael Paquier @ 2022-10-31 05:42 UTC (permalink / raw) To: Postgres hackers <[email protected]> Hi all, As per the world clock, the next commit fest will begin in 30 hours (11/1 0:00 AoE time). I may have missed something, but it looks like we have no CFM for this one yet. Opinions, thoughts or volunteers? -- Michael Attachments: [application/pgp-signature] signature.asc (833B, ../../[email protected]/2-signature.asc) download ^ permalink raw reply [nested|flat] 29+ messages in thread
* Re: Commit fest 2022-11 @ 2022-11-01 01:01 Ian Lawrence Barwick <[email protected]> parent: Michael Paquier <[email protected]> 1 sibling, 2 replies; 29+ messages in thread From: Ian Lawrence Barwick @ 2022-11-01 01:01 UTC (permalink / raw) To: Michael Paquier <[email protected]>; +Cc: Postgres hackers <[email protected]> 2022年10月31日(月) 14:42 Michael Paquier <[email protected]>: > > Hi all, > > As per the world clock, the next commit fest will begin in 30 hours > (11/1 0:00 AoE time). I may have missed something, but it looks like > we have no CFM for this one yet. ** tumbleweed ** > Opinions, thoughts or volunteers? This is on my bucket list of things to do some day, so I guess now is as bad a time as any :). Caveat is that this will have to be a personal free-time project, so would be good if someone else is around as well. Regards Ian Barwick ^ permalink raw reply [nested|flat] 29+ messages in thread
* Re: Commit fest 2022-11 @ 2022-11-01 04:26 jian he <[email protected]> parent: Ian Lawrence Barwick <[email protected]> 1 sibling, 1 reply; 29+ messages in thread From: jian he @ 2022-11-01 04:26 UTC (permalink / raw) To: Ian Lawrence Barwick <[email protected]>; +Cc: Michael Paquier <[email protected]>; Postgres hackers <[email protected]> On Tue, Nov 1, 2022 at 6:31 AM Ian Lawrence Barwick <[email protected]> wrote: > 2022年10月31日(月) 14:42 Michael Paquier <[email protected]>: > > > > Hi all, > > > > As per the world clock, the next commit fest will begin in 30 hours > > (11/1 0:00 AoE time). I may have missed something, but it looks like > > we have no CFM for this one yet. > > ** tumbleweed ** > > > Opinions, thoughts or volunteers? > > This is on my bucket list of things to do some day, so I guess now is as > bad a > time as any :). Caveat is that this will have to be a personal > free-time project, > so would be good if someone else is around as well. > > Regards > > Ian Barwick > > > I am free. I can help. -- I recommend David Deutsch's <<The Beginning of Infinity>> Jian ^ permalink raw reply [nested|flat] 29+ messages in thread
* Re: Commit fest 2022-11 @ 2022-11-01 04:35 Michael Paquier <[email protected]> parent: jian he <[email protected]> 0 siblings, 0 replies; 29+ messages in thread From: Michael Paquier @ 2022-11-01 04:35 UTC (permalink / raw) To: jian he <[email protected]>; +Cc: Ian Lawrence Barwick <[email protected]>; Postgres hackers <[email protected]> On Tue, Nov 01, 2022 at 09:56:47AM +0530, jian he wrote: > I am free. I can help. Commit fest managers are usually people who have a few years of experience behind the community process. There are plenty of patches to review, so feel free to pick up a few things and help moving these, of course! Thanks. -- Michael Attachments: [application/pgp-signature] signature.asc (833B, ../../[email protected]/2-signature.asc) download ^ permalink raw reply [nested|flat] 29+ messages in thread
* Re: Commit fest 2022-11 @ 2022-11-01 04:40 Michael Paquier <[email protected]> parent: Ian Lawrence Barwick <[email protected]> 1 sibling, 1 reply; 29+ messages in thread From: Michael Paquier @ 2022-11-01 04:40 UTC (permalink / raw) To: Ian Lawrence Barwick <[email protected]>; +Cc: Postgres hackers <[email protected]> On Tue, Nov 01, 2022 at 10:01:05AM +0900, Ian Lawrence Barwick wrote: > This is on my bucket list of things to do some day, so I guess now is as bad a > time as any :). Caveat is that this will have to be a personal > free-time project, > so would be good if someone else is around as well. Don't worry, we all have priorities. I'll be around, so I'll help you with all that, switching the status of the CF in a couple of hours. (Let's discuss in person if necessary next week, I guess?) -- Michael Attachments: [application/pgp-signature] signature.asc (833B, ../../[email protected]/2-signature.asc) download ^ permalink raw reply [nested|flat] 29+ messages in thread
* Re: Commit fest 2022-11 @ 2022-11-01 08:59 Simon Riggs <[email protected]> parent: Michael Paquier <[email protected]> 1 sibling, 1 reply; 29+ messages in thread From: Simon Riggs @ 2022-11-01 08:59 UTC (permalink / raw) To: Michael Paquier <[email protected]>; +Cc: Postgres hackers <[email protected]> On Mon, 31 Oct 2022 at 05:42, Michael Paquier <[email protected]> wrote: > As per the world clock, the next commit fest will begin in 30 hours > (11/1 0:00 AoE time). I may have missed something, but it looks like > we have no CFM for this one yet. > > Opinions, thoughts or volunteers? If we have no volunteers, maybe it is because the job of CFM is too big now and needs to be split. I can offer to be co-CFM, and think I can offer to be CFM for about 100 patches, but I don't have the time to do the whole thing myself. -- Simon Riggs http://www.EnterpriseDB.com/ ^ permalink raw reply [nested|flat] 29+ messages in thread
* Re: Commit fest 2022-11 @ 2022-11-01 10:10 Ian Lawrence Barwick <[email protected]> parent: Michael Paquier <[email protected]> 0 siblings, 1 reply; 29+ messages in thread From: Ian Lawrence Barwick @ 2022-11-01 10:10 UTC (permalink / raw) To: Michael Paquier <[email protected]>; +Cc: Postgres hackers <[email protected]> 2022年11月1日(火) 13:40 Michael Paquier <[email protected]>: > > On Tue, Nov 01, 2022 at 10:01:05AM +0900, Ian Lawrence Barwick wrote: > > This is on my bucket list of things to do some day, so I guess now is as bad a > > time as any :). Caveat is that this will have to be a personal > > free-time project, > > so would be good if someone else is around as well. > > Don't worry, we all have priorities. I'll be around, so I'll help you > with all that, switching the status of the CF in a couple of hours. > > (Let's discuss in person if necessary next week, I guess?) Yup, Monday by the looks of it. My community login is "barwick", in case needed. Regards Ian Barwick ^ permalink raw reply [nested|flat] 29+ messages in thread
* Re: Commit fest 2022-11 @ 2022-11-01 10:15 Ian Lawrence Barwick <[email protected]> parent: Simon Riggs <[email protected]> 0 siblings, 1 reply; 29+ messages in thread From: Ian Lawrence Barwick @ 2022-11-01 10:15 UTC (permalink / raw) To: Simon Riggs <[email protected]>; +Cc: Michael Paquier <[email protected]>; Postgres hackers <[email protected]> 2022年11月1日(火) 17:59 Simon Riggs <[email protected]>: > > On Mon, 31 Oct 2022 at 05:42, Michael Paquier <[email protected]> wrote: > > > As per the world clock, the next commit fest will begin in 30 hours > > (11/1 0:00 AoE time). I may have missed something, but it looks like > > we have no CFM for this one yet. > > > > Opinions, thoughts or volunteers? > > If we have no volunteers, maybe it is because the job of CFM is too > big now and needs to be split. ^ permalink raw reply [nested|flat] 29+ messages in thread
* Re: Commit fest 2022-11 @ 2022-11-01 10:55 Michael Paquier <[email protected]> parent: Ian Lawrence Barwick <[email protected]> 0 siblings, 1 reply; 29+ messages in thread From: Michael Paquier @ 2022-11-01 10:55 UTC (permalink / raw) To: Ian Lawrence Barwick <[email protected]>; +Cc: Simon Riggs <[email protected]>; Postgres hackers <[email protected]> On Tue, Nov 01, 2022 at 07:15:34PM +0900, Ian Lawrence Barwick wrote: > From casual observation it's been like that for the last few CFs, i.e. there > have been effectively two CFMs. > > I am on record as volunteering earlier in the thread, with the caveat that there > will be a limit on what I can do :). Two people showing up to help is really great, thanks! I'll be around as well this month, so I'll do my share of patches, as usual. -- Michael Attachments: [application/pgp-signature] signature.asc (833B, ../../[email protected]/2-signature.asc) download ^ permalink raw reply [nested|flat] 29+ messages in thread
* Re: Commit fest 2022-11 @ 2022-11-01 10:59 Michael Paquier <[email protected]> parent: Ian Lawrence Barwick <[email protected]> 0 siblings, 1 reply; 29+ messages in thread From: Michael Paquier @ 2022-11-01 10:59 UTC (permalink / raw) To: Ian Lawrence Barwick <[email protected]>; +Cc: Postgres hackers <[email protected]> On Tue, Nov 01, 2022 at 07:10:15PM +0900, Ian Lawrence Barwick wrote: > Yup, Monday by the looks of it. > > My community login is "barwick", in case needed. Adding Magnus in CC, in case you need the admin permissions on the CF app. (I have no idea how to do it, and I likely lack the permissions to do that anyway.) -- Michael Attachments: [application/pgp-signature] signature.asc (833B, ../../[email protected]/2-signature.asc) download ^ permalink raw reply [nested|flat] 29+ messages in thread
* Re: Commit fest 2022-11 @ 2022-11-01 16:36 Magnus Hagander <[email protected]> parent: Michael Paquier <[email protected]> 0 siblings, 1 reply; 29+ messages in thread From: Magnus Hagander @ 2022-11-01 16:36 UTC (permalink / raw) To: Michael Paquier <[email protected]>; +Cc: Ian Lawrence Barwick <[email protected]>; Postgres hackers <[email protected]> On Tue, Nov 1, 2022 at 11:59 AM Michael Paquier <[email protected]> wrote: > On Tue, Nov 01, 2022 at 07:10:15PM +0900, Ian Lawrence Barwick wrote: > > Yup, Monday by the looks of it. > > > > My community login is "barwick", in case needed. > > Adding Magnus in CC, in case you need the admin permissions on the CF > app. (I have no idea how to do it, and I likely lack the permissions > to do that anyway.) > > Permissions added! -- Magnus Hagander Me: https://www.hagander.net/ <http://www.hagander.net/; Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/; ^ permalink raw reply [nested|flat] 29+ messages in thread
* Re: Commit fest 2022-11 @ 2022-11-01 23:21 Ian Lawrence Barwick <[email protected]> parent: Magnus Hagander <[email protected]> 0 siblings, 0 replies; 29+ messages in thread From: Ian Lawrence Barwick @ 2022-11-01 23:21 UTC (permalink / raw) To: Magnus Hagander <[email protected]>; +Cc: Michael Paquier <[email protected]>; Postgres hackers <[email protected]> 2022年11月2日(水) 1:36 Magnus Hagander <[email protected]>:> > On Tue, Nov 1, 2022 at 11:59 AM Michael Paquier <[email protected]> wrote: >> >> On Tue, Nov 01, 2022 at 07:10:15PM +0900, Ian Lawrence Barwick wrote: >> > Yup, Monday by the looks of it. >> > >> > My community login is "barwick", in case needed. >> >> Adding Magnus in CC, in case you need the admin permissions on the CF >> app. (I have no idea how to do it, and I likely lack the permissions >> to do that anyway.) >> > > Permissions added! Thanks, I see the extra menu link. Regards Ian Barwick ^ permalink raw reply [nested|flat] 29+ messages in thread
* Re: Commit fest 2022-11 @ 2022-11-02 10:10 Greg Stark <[email protected]> parent: Michael Paquier <[email protected]> 0 siblings, 1 reply; 29+ messages in thread From: Greg Stark @ 2022-11-02 10:10 UTC (permalink / raw) To: Michael Paquier <[email protected]>; +Cc: Ian Lawrence Barwick <[email protected]>; Simon Riggs <[email protected]>; Postgres hackers <[email protected]> On Tue, 1 Nov 2022 at 06:56, Michael Paquier <[email protected]> wrote: > Two people showing up to help is really great, thanks! I'll be around > as well this month, so I'll do my share of patches, as usual. Fwiw I can help as well -- starting next week. I can't do much this week though. I would suggest starting with the cfbot to mark anything that isn't applying cleanly and passing tests (and looking for more than design feedback) as Waiting on Author and reminding the author that it's commitfest time and a good time to bring the patch into a clean state. -- greg ^ permalink raw reply [nested|flat] 29+ messages in thread
* Re: Commit fest 2022-11 @ 2022-11-03 02:33 Ian Lawrence Barwick <[email protected]> parent: Greg Stark <[email protected]> 0 siblings, 2 replies; 29+ messages in thread From: Ian Lawrence Barwick @ 2022-11-03 02:33 UTC (permalink / raw) To: Greg Stark <[email protected]>; +Cc: Michael Paquier <[email protected]>; Simon Riggs <[email protected]>; Postgres hackers <[email protected]> 2022年11月2日(水) 19:10 Greg Stark <[email protected]>: > > On Tue, 1 Nov 2022 at 06:56, Michael Paquier <[email protected]> wrote: > > > Two people showing up to help is really great, thanks! I'll be around > > as well this month, so I'll do my share of patches, as usual. > > Fwiw I can help as well -- starting next week. I can't do much this week though. > > I would suggest starting with the cfbot to mark anything that isn't > applying cleanly and passing tests (and looking for more than design > feedback) as Waiting on Author and reminding the author that it's > commitfest time and a good time to bring the patch into a clean state. Sounds like a plan; I'll make a start on that today/tomorrow as I have some time. Regards Ian Barwick ^ permalink raw reply [nested|flat] 29+ messages in thread
* Re: Commit fest 2022-11 @ 2022-11-03 09:48 Ian Lawrence Barwick <[email protected]> parent: Ian Lawrence Barwick <[email protected]> 1 sibling, 1 reply; 29+ messages in thread From: Ian Lawrence Barwick @ 2022-11-03 09:48 UTC (permalink / raw) To: Greg Stark <[email protected]>; +Cc: Michael Paquier <[email protected]>; Simon Riggs <[email protected]>; Postgres hackers <[email protected]> 2022年11月3日(木) 11:33 Ian Lawrence Barwick <[email protected]>: > > 2022年11月2日(水) 19:10 Greg Stark <[email protected]>: > > > > On Tue, 1 Nov 2022 at 06:56, Michael Paquier <[email protected]> wrote: > > > > > Two people showing up to help is really great, thanks! I'll be around > > > as well this month, so I'll do my share of patches, as usual. > > > > Fwiw I can help as well -- starting next week. I can't do much this week though. > > > > I would suggest starting with the cfbot to mark anything that isn't > > applying cleanly and passing tests (and looking for more than design > > feedback) as Waiting on Author and reminding the author that it's > > commitfest time and a good time to bring the patch into a clean state. > > Sounds like a plan; I'll make a start on that today/tomorrow as I have > some time. Ploughing through the list, initially those where the patches don't apply. I am wondering what the best thing to do with cases like this is: https://commitfest.postgresql.org/40/3977/ where there were multiple patches in the original post, and some but not all were applied - so those ones are now failing to apply in the cfbot. Should we request the author to update the thread with those patches which are still pending? Regards Ian Barwick ^ permalink raw reply [nested|flat] 29+ messages in thread
* Re: Commit fest 2022-11 @ 2022-11-03 11:58 Michael Paquier <[email protected]> parent: Ian Lawrence Barwick <[email protected]> 0 siblings, 0 replies; 29+ messages in thread From: Michael Paquier @ 2022-11-03 11:58 UTC (permalink / raw) To: Ian Lawrence Barwick <[email protected]>; +Cc: Greg Stark <[email protected]>; Simon Riggs <[email protected]>; Postgres hackers <[email protected]> On Thu, Nov 03, 2022 at 06:48:34PM +0900, Ian Lawrence Barwick wrote: > I am wondering what the best thing to do with cases like this is: > > https://commitfest.postgresql.org/40/3977/ > > where there were multiple patches in the original post, and some but not all > were applied - so those ones are now failing to apply in the cfbot. Should we > request the author to update the thread with those patches which are > still pending? A case-by-case analysis is usually adapted, but if subject is not over yet, and only a portion of the patches have been addressed, keeping it around is the best course of action IMO. The author and/or reviewer may decide otherwise later on, or the patch could always be revisited at the end of the CF and marked as committed, though it would be good to update the thread to reflect that. By experience, it does not happen that often. -- Michael Attachments: [application/pgp-signature] signature.asc (833B, ../../[email protected]/2-signature.asc) download ^ permalink raw reply [nested|flat] 29+ messages in thread
* Re: Commit fest 2022-11 @ 2022-11-04 00:43 Justin Pryzby <[email protected]> parent: Ian Lawrence Barwick <[email protected]> 1 sibling, 2 replies; 29+ messages in thread From: Justin Pryzby @ 2022-11-04 00:43 UTC (permalink / raw) To: Ian Lawrence Barwick <[email protected]>; +Cc: Greg Stark <[email protected]>; Michael Paquier <[email protected]>; Simon Riggs <[email protected]>; [email protected] On Thu, Nov 03, 2022 at 11:33:57AM +0900, Ian Lawrence Barwick wrote: > 2022年11月2日(水) 19:10 Greg Stark <[email protected]>: > > > > On Tue, 1 Nov 2022 at 06:56, Michael Paquier <[email protected]> wrote: > > > > > Two people showing up to help is really great, thanks! I'll be around > > > as well this month, so I'll do my share of patches, as usual. > > > > Fwiw I can help as well -- starting next week. I can't do much this week though. > > > > I would suggest starting with the cfbot to mark anything that isn't > > applying cleanly and passing tests (and looking for more than design > > feedback) as Waiting on Author and reminding the author that it's > > commitfest time and a good time to bring the patch into a clean state. > > Sounds like a plan; I'll make a start on that today/tomorrow as I have > some time. If I'm not wrong, Jacob used the CF app to bulk-mail people about patches not applying and similar things. That seemed to work well, and doesn't require sending mails to dozens of threads. -- Justin ^ permalink raw reply [nested|flat] 29+ messages in thread
* Re: Commit fest 2022-11 @ 2022-11-04 01:23 Ian Lawrence Barwick <[email protected]> parent: Justin Pryzby <[email protected]> 1 sibling, 1 reply; 29+ messages in thread From: Ian Lawrence Barwick @ 2022-11-04 01:23 UTC (permalink / raw) To: Justin Pryzby <[email protected]>; +Cc: Greg Stark <[email protected]>; Michael Paquier <[email protected]>; Simon Riggs <[email protected]>; [email protected] 2022年11月4日(金) 9:43 Justin Pryzby <[email protected]>: > > On Thu, Nov 03, 2022 at 11:33:57AM +0900, Ian Lawrence Barwick wrote: > > 2022年11月2日(水) 19:10 Greg Stark <[email protected]>: > > > > > > On Tue, 1 Nov 2022 at 06:56, Michael Paquier <[email protected]> wrote: > > > > > > > Two people showing up to help is really great, thanks! I'll be around > > > > as well this month, so I'll do my share of patches, as usual. > > > > > > Fwiw I can help as well -- starting next week. I can't do much this week though. > > > > > > I would suggest starting with the cfbot to mark anything that isn't > > > applying cleanly and passing tests (and looking for more than design > > > feedback) as Waiting on Author and reminding the author that it's > > > commitfest time and a good time to bring the patch into a clean state. > > > > Sounds like a plan; I'll make a start on that today/tomorrow as I have > > some time. > > If I'm not wrong, Jacob used the CF app to bulk-mail people about > patches not applying and similar things. That seemed to work well, and > doesn't require sending mails to dozens of threads. I don't see anything like that in the CF app (though I may be looking in the wrong place). I also don't see how it would be possible to filter on patches not applying in cbfot, as AFAICT the former is not aware of the latter. There is an option for each entry to send an email from the CF app, but it comes with a note "Please ensure that the email settings for your domain (DKIM, SPF) allow emails from external sources." which I fear would lead to email delivery issues. Regards Ian Barwick ^ permalink raw reply [nested|flat] 29+ messages in thread
* Re: Commit fest 2022-11 @ 2022-11-04 05:18 Ian Lawrence Barwick <[email protected]> parent: Ian Lawrence Barwick <[email protected]> 0 siblings, 1 reply; 29+ messages in thread From: Ian Lawrence Barwick @ 2022-11-04 05:18 UTC (permalink / raw) To: Justin Pryzby <[email protected]>; +Cc: Greg Stark <[email protected]>; Michael Paquier <[email protected]>; Simon Riggs <[email protected]>; [email protected] 2022年11月4日(金) 10:23 Ian Lawrence Barwick <[email protected]>: > > 2022年11月4日(金) 9:43 Justin Pryzby <[email protected]>: > > > > On Thu, Nov 03, 2022 at 11:33:57AM +0900, Ian Lawrence Barwick wrote: > > > 2022年11月2日(水) 19:10 Greg Stark <[email protected]>: > > > > > > > > On Tue, 1 Nov 2022 at 06:56, Michael Paquier <[email protected]> wrote: > > > > > > > > > Two people showing up to help is really great, thanks! I'll be around > > > > > as well this month, so I'll do my share of patches, as usual. > > > > > > > > Fwiw I can help as well -- starting next week. I can't do much this week though. > > > > > > > > I would suggest starting with the cfbot to mark anything that isn't > > > > applying cleanly and passing tests (and looking for more than design > > > > feedback) as Waiting on Author and reminding the author that it's > > > > commitfest time and a good time to bring the patch into a clean state. > > > > > > Sounds like a plan; I'll make a start on that today/tomorrow as I have > > > some time. > > > > If I'm not wrong, Jacob used the CF app to bulk-mail people about > > patches not applying and similar things. That seemed to work well, and > > doesn't require sending mails to dozens of threads. > > I don't see anything like that in the CF app (though I may be looking in the > wrong place). I also don't see how it would be possible to filter on patches > not applying in cbfot, as AFAICT the former is not aware of the latter.Also, having gone through all the cfbot items with non-applying patches (single red "X"), sending a reminder without checking further doesn't seem the right thing tod do - in two cases the patch was not applying because it had already been committed, and with another the consensus was to return it with feedback. With others, it's obvious the threads were recently active and I don't think a reminder is necessary right now. Please do however let me know if I should be doing something differently. Anyway changes since yesterday: Needs review: 164 -> 156 Waiting on Author: 64 -> 68 Ready for Committer: 22 -> 21 Committed: 43 -> 47 Withdrawn: 9 -> 9 Rejected: 1 -> 1 Returned with Feedback: 4 -> 5 Following entries are reported with patch apply failure, but it's less clear (to me) whether a simple request to update the patch is what is needed at this point, because e.g. the thread is long and complex, or has been fairly inactive for a while: - "AcquireExecutorLocks() and run-time pruning" https://commitfest.postgresql.org/40/3478/ - "pg_stat_activity: avoid showing state=active with wait_event=ClientRead" https://commitfest.postgresql.org/40/3760/ - "logical decoding and replication of sequences, take 2" https://commitfest.postgresql.org/40/3823/ - "Lazy JIT IR code generation to increase JIT speed with partitions" https://commitfest.postgresql.org/40/3071/ - "Collation version and dependency helpers" https://commitfest.postgresql.org/40/3977/ - "Time-delayed logical replication subscriber" http://cfbot.cputube.org/patch_40_3581.log - "Fix checkpointer sync request queue problems" https://commitfest.postgresql.org/40/3583/ - "Nonreplayable XLog records by means of overflows and >MaxAllocSize lengths" https://commitfest.postgresql.org/40/3590/ - "Transparent column encryption" https://commitfest.postgresql.org/40/3718/ The following have all received requests to update the patch(s), and have been set to "Waiting on Author" where not already done: - "XID formatting and SLRU refactorings (Independent part of: Add 64-bit XIDs into PostgreSQL 15)" https://commitfest.postgresql.org/40/3489/ (-> patches already updated; changed back to "WfC") - "Add index scan progress to pg_stat_progress_vacuum" https://commitfest.postgresql.org/40/3617/ - "Adding CommandID to heap xlog records" https://commitfest.postgresql.org/40/3882/ - "Add semi-join pushdown to postgres_fdw" https://commitfest.postgresql.org/40/3838/ - "Completed unaccent dictionary with many missing characters" https://commitfest.postgresql.org/40/3631/ - "Data is copied twice when specifying both child and parent table in publication" https://commitfest.postgresql.org/40/3623/ - "Fix ExecRTCheckPerms() inefficiency with many prunable partitions " https://commitfest.postgresql.org/40/3224/ - "In-place persistence change of a relation" https://commitfest.postgresql.org/40/3461/ - "Move SLRU data into the regular buffer pool" https://commitfest.postgresql.org/40/3514/ - "New [relation] options engine" https://commitfest.postgresql.org/40/3536/ - "Nonreplayable XLog records by means of overflows and >MaxAllocSize lengths" https://commitfest.postgresql.org/40/3590/ - "Page compression for OLTP" https://commitfest.postgresql.org/40/3783/ - "Provide the facility to set binary format output for specific OID's per session" https://commitfest.postgresql.org/40/3777/ - "Reducing power consumption when idle" https://commitfest.postgresql.org/40/3566/ - "Reuse Workers and Replication Slots during Logical Replication" https://commitfest.postgresql.org/40/3784/ - "Skip replicating the tables specified in except table option" https://commitfest.postgresql.org/40/3646/ - "Teach pg_waldump to extract FPIs from the WAL stream" https://commitfest.postgresql.org/40/3628/ - "[PATCH] Equivalence Class Filters" https://commitfest.postgresql.org/40/3524/ - "improve handling for misconfigured archiving parameters" https://commitfest.postgresql.org/40/3933/ - "logical decoding and replication of sequences, take 2" https://commitfest.postgresql.org/40/3823/ Following open entries had actually already been committed: - Improve description of XLOG_RUNNING_XACTS https://commitfest.postgresql.org/40/3779/ - "Add native windows on arm64 support" https://commitfest.postgresql.org/40/3561/ Following entry was set to "Returned with feedback": - "On client login event trigger" https://commitfest.postgresql.org/40/2900/ Regards Ian Barwick ^ permalink raw reply [nested|flat] 29+ messages in thread
* Re: Commit fest 2022-11 @ 2022-11-04 20:18 Jacob Champion <[email protected]> parent: Ian Lawrence Barwick <[email protected]> 0 siblings, 0 replies; 29+ messages in thread From: Jacob Champion @ 2022-11-04 20:18 UTC (permalink / raw) To: Ian Lawrence Barwick <[email protected]>; Justin Pryzby <[email protected]>; +Cc: Greg Stark <[email protected]>; Michael Paquier <[email protected]>; Simon Riggs <[email protected]>; [email protected] On 11/3/22 22:18, Ian Lawrence Barwick wrote: > 2022年11月4日(金) 10:23 Ian Lawrence Barwick <[email protected] > <mailto:[email protected]>>: >> 2022年11月4日(金) 9:43 Justin Pryzby <[email protected] > <mailto:[email protected]>>: >> > If I'm not wrong, Jacob used the CF app to bulk-mail people about >> > patches not applying and similar things. That seemed to work well, and >> > doesn't require sending mails to dozens of threads. >> >> I don't see anything like that in the CF app (though I may be looking in the >> wrong place). I just used the "email author" checkboxes. >> I also don't see how it would be possible to filter on patches >> not applying in cbfot, as AFAICT the former is not aware of the latter. That was the hard part. I ended up manually merging the two pages locally. > Also, having gone through all the cfbot items with non-applying > patches (single red "X"), sending a reminder without checking > further doesn't seem the right thing tod do - in two cases the patch > was not applying because it had already been committed, and with > another the consensus was to return it with feedback. With others, > it's obvious the threads were recently active and I don't think a > reminder is necessary right now. True. One nice thing about the author-only email is that, as long as you don't send reminders too often (I think there'd been talk before of once, maximum twice, per CF?) then if an author feels there's no reason to take action, they don't have to. That low-effort strategy also scales a bit better than making a CFM scan manually, and it's a bit closer in my opinion to the automated reminder feature that's been requested frequently. > There is an option for each entry to send an email from the CF app, but it comes > with a note "Please ensure that the email settings for your domain (DKIM, SPF) > allow emails from external sources." which I fear would lead to email > delivery issues. I know some of my bulk emails were delivered to spam folders, so it is a fair concern. --Jacob ^ permalink raw reply [nested|flat] 29+ messages in thread
* Re: Commit fest 2022-11 @ 2022-11-08 23:12 Justin Pryzby <[email protected]> parent: Justin Pryzby <[email protected]> 1 sibling, 1 reply; 29+ messages in thread From: Justin Pryzby @ 2022-11-08 23:12 UTC (permalink / raw) To: Ian Lawrence Barwick <[email protected]>; +Cc: Greg Stark <[email protected]>; Michael Paquier <[email protected]>; Simon Riggs <[email protected]>; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected] On Thu, Nov 03, 2022 at 07:43:03PM -0500, Justin Pryzby wrote: > On Thu, Nov 03, 2022 at 11:33:57AM +0900, Ian Lawrence Barwick wrote: > > 2022年11月2日(水) 19:10 Greg Stark <[email protected]>: > > > On Tue, 1 Nov 2022 at 06:56, Michael Paquier <[email protected]> wrote: > > > > > > > Two people showing up to help is really great, thanks! I'll be around > > > > as well this month, so I'll do my share of patches, as usual. > > > > > > Fwiw I can help as well -- starting next week. I can't do much this week though. > > > > > > I would suggest starting with the cfbot to mark anything that isn't > > > applying cleanly and passing tests (and looking for more than design > > > feedback) as Waiting on Author and reminding the author that it's > > > commitfest time and a good time to bring the patch into a clean state. > > > > Sounds like a plan; I'll make a start on that today/tomorrow as I have > > some time. > > If I'm not wrong, Jacob used the CF app to bulk-mail people about > patches not applying and similar things. That seemed to work well, and > doesn't require sending mails to dozens of threads. If my script is not wrong, these patches add TAP tests, but don't update the requisite ./meson.build file. It seems like it'd be reasonable to set them all as WOA until that's done. $ for a in `git branch -a |sort |grep commitfest/40`; do : echo "$a..."; x=`git log -1 --compact-summary "$a"`; echo "$x" |grep '/t/.*pl.*new' >/dev/null || continue; echo "$x" |grep -Fw meson >/dev/null && continue; git log -1 --oneline "$a"; done ... [CF 40/3558] Allow file inclusion in pg_hba and pg_ident files ... [CF 40/3628] Teach pg_waldump to extract FPIs from the WAL stream ... [CF 40/3646] Skip replicating the tables specified in except table option ... [CF 40/3663] Switching XLog source from archive to streaming when primary available ... [CF 40/3670] pg_rewind: warn when checkpoint hasn't happened after promotion ... [CF 40/3729] Testing autovacuum wraparound ... [CF 40/3877] vacuumlo: add test to vacuumlo for test coverage ... [CF 40/3985] TDE key management patches -- Justin ^ permalink raw reply [nested|flat] 29+ messages in thread
* Re: Commit fest 2022-11 @ 2022-11-14 12:08 Ian Lawrence Barwick <[email protected]> parent: Justin Pryzby <[email protected]> 0 siblings, 1 reply; 29+ messages in thread From: Ian Lawrence Barwick @ 2022-11-14 12:08 UTC (permalink / raw) To: Justin Pryzby <[email protected]>; +Cc: Greg Stark <[email protected]>; Michael Paquier <[email protected]>; Simon Riggs <[email protected]>; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected] 2022年11月9日(水) 8:12 Justin Pryzby <[email protected]>: > > On Thu, Nov 03, 2022 at 07:43:03PM -0500, Justin Pryzby wrote: > > On Thu, Nov 03, 2022 at 11:33:57AM +0900, Ian Lawrence Barwick wrote: > > > 2022年11月2日(水) 19:10 Greg Stark <[email protected]>: > > > > On Tue, 1 Nov 2022 at 06:56, Michael Paquier <[email protected]> wrote: > > > > > > > > > Two people showing up to help is really great, thanks! I'll be around > > > > > as well this month, so I'll do my share of patches, as usual. > > > > > > > > Fwiw I can help as well -- starting next week. I can't do much this week though. > > > > > > > > I would suggest starting with the cfbot to mark anything that isn't > > > > applying cleanly and passing tests (and looking for more than design > > > > feedback) as Waiting on Author and reminding the author that it's > > > > commitfest time and a good time to bring the patch into a clean state. > > > > > > Sounds like a plan; I'll make a start on that today/tomorrow as I have > > > some time. > > > > If I'm not wrong, Jacob used the CF app to bulk-mail people about > > patches not applying and similar things. That seemed to work well, and > > doesn't require sending mails to dozens of threads. > > If my script is not wrong, these patches add TAP tests, but don't update > the requisite ./meson.build file. It seems like it'd be reasonable to > set them all as WOA until that's done. > > $ for a in `git branch -a |sort |grep commitfest/40`; do : echo "$a..."; x=`git log -1 --compact-summary "$a"`; echo "$x" |grep '/t/.*pl.*new' >/dev/null || continue; echo "$x" |grep -Fw meson >/dev/null && continue; git log -1 --oneline "$a"; done > ... [CF 40/3558] Allow file inclusion in pg_hba and pg_ident files > ... [CF 40/3628] Teach pg_waldump to extract FPIs from the WAL stream > ... [CF 40/3646] Skip replicating the tables specified in except table option > ... [CF 40/3663] Switching XLog source from archive to streaming when primary available > ... [CF 40/3670] pg_rewind: warn when checkpoint hasn't happened after promotion > ... [CF 40/3729] Testing autovacuum wraparound > ... [CF 40/3877] vacuumlo: add test to vacuumlo for test coverage > ... [CF 40/3985] TDE key management patches Looks like your script is correct, will update accordingly. Do we have a FAQ/checklist of meson things to consider for patches anywhere? Regards Ian Barwick ^ permalink raw reply [nested|flat] 29+ messages in thread
* Re: Commit fest 2022-11 @ 2022-11-14 13:23 James Coleman <[email protected]> parent: Ian Lawrence Barwick <[email protected]> 0 siblings, 1 reply; 29+ messages in thread From: James Coleman @ 2022-11-14 13:23 UTC (permalink / raw) To: Ian Lawrence Barwick <[email protected]>; +Cc: Justin Pryzby <[email protected]>; Greg Stark <[email protected]>; Michael Paquier <[email protected]>; Simon Riggs <[email protected]>; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected] On Mon, Nov 14, 2022 at 7:08 AM Ian Lawrence Barwick <[email protected]> wrote: > > 2022年11月9日(水) 8:12 Justin Pryzby <[email protected]>: .... > > If my script is not wrong, these patches add TAP tests, but don't update > > the requisite ./meson.build file. It seems like it'd be reasonable to > > set them all as WOA until that's done. > > > > $ for a in `git branch -a |sort |grep commitfest/40`; do : echo "$a..."; x=`git log -1 --compact-summary "$a"`; echo "$x" |grep '/t/.*pl.*new' >/dev/null || continue; echo "$x" |grep -Fw meson >/dev/null && continue; git log -1 --oneline "$a"; done > > ... [CF 40/3558] Allow file inclusion in pg_hba and pg_ident files > > ... [CF 40/3628] Teach pg_waldump to extract FPIs from the WAL stream > > ... [CF 40/3646] Skip replicating the tables specified in except table option > > ... [CF 40/3663] Switching XLog source from archive to streaming when primary available > > ... [CF 40/3670] pg_rewind: warn when checkpoint hasn't happened after promotion > > ... [CF 40/3729] Testing autovacuum wraparound > > ... [CF 40/3877] vacuumlo: add test to vacuumlo for test coverage > > ... [CF 40/3985] TDE key management patches > > Looks like your script is correct, will update accordingly. > > Do we have a FAQ/checklist of meson things to consider for patches anywhere? It's possible this has been discussed before, but it seems less than ideal to have notifications about moving to WOA be sent only in a bulk email hanging off the "current CF" email chain as opposed to being sent to the individual threads. Perhaps that's something the app should do for us in this situation. Without that though the patch authors are left to wade through unrelated discussion, and, probably more importantly, the patch discussion thread doesn't show the current state (I think bumping there is more likely to prompt activity as well). James Coleman ^ permalink raw reply [nested|flat] 29+ messages in thread
* Re: Commit fest 2022-11 @ 2022-11-14 13:38 Ian Lawrence Barwick <[email protected]> parent: James Coleman <[email protected]> 0 siblings, 1 reply; 29+ messages in thread From: Ian Lawrence Barwick @ 2022-11-14 13:38 UTC (permalink / raw) To: James Coleman <[email protected]>; +Cc: Justin Pryzby <[email protected]>; Greg Stark <[email protected]>; Michael Paquier <[email protected]>; Simon Riggs <[email protected]>; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected] 2022年11月14日(月) 22:23 James Coleman <[email protected]>: > > On Mon, Nov 14, 2022 at 7:08 AM Ian Lawrence Barwick <[email protected]> wrote: > > > > 2022年11月9日(水) 8:12 Justin Pryzby <[email protected]>: > .... > > > If my script is not wrong, these patches add TAP tests, but don't update > > > the requisite ./meson.build file. It seems like it'd be reasonable to > > > set them all as WOA until that's done. > > > > > > $ for a in `git branch -a |sort |grep commitfest/40`; do : echo "$a..."; x=`git log -1 --compact-summary "$a"`; echo "$x" |grep '/t/.*pl.*new' >/dev/null || continue; echo "$x" |grep -Fw meson >/dev/null && continue; git log -1 --oneline "$a"; done > > > ... [CF 40/3558] Allow file inclusion in pg_hba and pg_ident files > > > ... [CF 40/3628] Teach pg_waldump to extract FPIs from the WAL stream > > > ... [CF 40/3646] Skip replicating the tables specified in except table option > > > ... [CF 40/3663] Switching XLog source from archive to streaming when primary available > > > ... [CF 40/3670] pg_rewind: warn when checkpoint hasn't happened after promotion > > > ... [CF 40/3729] Testing autovacuum wraparound > > > ... [CF 40/3877] vacuumlo: add test to vacuumlo for test coverage > > > ... [CF 40/3985] TDE key management patches > > > > Looks like your script is correct, will update accordingly. > > > > It's possible this has been discussed before, but it seems less than > ideal to have notifications about moving to WOA be sent only in a bulk > email hanging off the "current CF" email chain as opposed to being > sent to the individual threads. Perhaps that's something the app > should do for us in this situation. Without that though the patch > authors are left to wade through unrelated discussion, and, probably > more importantly, the patch discussion thread doesn't show the current > state (I think bumping there is more likely to prompt activity as > well). FWIW I've been manually "bumping" the respective threads, which is somewhat time-consuming but seems to have been quite productive in terms of getting patches updated. Will do same for the above once I've confirmed what is being requested, (which I presume is adding the new tests to the 'tests' array in the respective "meson.build" file; just taking the opportunity to familiariize myself with it). Regards Ian Barwick ^ permalink raw reply [nested|flat] 29+ messages in thread
* Re: Commit fest 2022-11 @ 2022-11-16 13:00 Ian Lawrence Barwick <[email protected]> parent: Ian Lawrence Barwick <[email protected]> 0 siblings, 1 reply; 29+ messages in thread From: Ian Lawrence Barwick @ 2022-11-16 13:00 UTC (permalink / raw) To: James Coleman <[email protected]>; +Cc: Justin Pryzby <[email protected]>; Greg Stark <[email protected]>; Michael Paquier <[email protected]>; Simon Riggs <[email protected]>; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected] 2022年11月14日(月) 22:38 Ian Lawrence Barwick <[email protected]>: > > 2022年11月14日(月) 22:23 James Coleman <[email protected]>: > > > > On Mon, Nov 14, 2022 at 7:08 AM Ian Lawrence Barwick <[email protected]> wrote: > > > > > > 2022年11月9日(水) 8:12 Justin Pryzby <[email protected]>: > > .... > > > > If my script is not wrong, these patches add TAP tests, but don't update > > > > the requisite ./meson.build file. It seems like it'd be reasonable to > > > > set them all as WOA until that's done. > > > > > > > > $ for a in `git branch -a |sort |grep commitfest/40`; do : echo "$a..."; x=`git log -1 --compact-summary "$a"`; echo "$x" |grep '/t/.*pl.*new' >/dev/null || continue; echo "$x" |grep -Fw meson >/dev/null && continue; git log -1 --oneline "$a"; done > > > > ... [CF 40/3558] Allow file inclusion in pg_hba and pg_ident files > > > > ... [CF 40/3628] Teach pg_waldump to extract FPIs from the WAL stream > > > > ... [CF 40/3646] Skip replicating the tables specified in except table option > > > > ... [CF 40/3663] Switching XLog source from archive to streaming when primary available > > > > ... [CF 40/3670] pg_rewind: warn when checkpoint hasn't happened after promotion > > > > ... [CF 40/3729] Testing autovacuum wraparound > > > > ... [CF 40/3877] vacuumlo: add test to vacuumlo for test coverage > > > > ... [CF 40/3985] TDE key management patches > > > > > > Looks like your script is correct, will update accordingly. > > > > > > > It's possible this has been discussed before, but it seems less than > > ideal to have notifications about moving to WOA be sent only in a bulk > > email hanging off the "current CF" email chain as opposed to being > > sent to the individual threads. Perhaps that's something the app > > should do for us in this situation. Without that though the patch > > authors are left to wade through unrelated discussion, and, probably > > more importantly, the patch discussion thread doesn't show the current > > state (I think bumping there is more likely to prompt activity as > > well). > > FWIW I've been manually "bumping" the respective threads, which is somewhat > time-consuming but seems to have been quite productive in terms of getting > patches updated. > > Will do same for the above once I've confirmed what is being requested, > (which I presume is adding the new tests to the 'tests' array in the respective > "meson.build" file; just taking the opportunity to familiariize myself with it). Various mails since sent to the appropriate threads; I took the opportunity to create a short wiki page: https://wiki.postgresql.org/wiki/Meson_for_patch_authors with relevant details (AFAICS) for anyone not familiar with meson; corrections/ improvements welcome. In the meantime I notice a number of patches in cfbot are currently failing on TAP test "test_custom_rmgrs/t/001_basic.pl" in some environments. This was added the other day in commit ae168c794f; there is already a fix for the issue ( 36e0358e70 ) but the cfbot doesn't have that commit yet. Regards Ian Barwick ^ permalink raw reply [nested|flat] 29+ messages in thread
* Re: Commit fest 2022-11 @ 2022-12-07 02:55 vignesh C <[email protected]> parent: Ian Lawrence Barwick <[email protected]> 0 siblings, 1 reply; 29+ messages in thread From: vignesh C @ 2022-12-07 02:55 UTC (permalink / raw) To: Ian Lawrence Barwick <[email protected]>; +Cc: James Coleman <[email protected]>; Justin Pryzby <[email protected]>; Greg Stark <[email protected]>; Michael Paquier <[email protected]>; Simon Riggs <[email protected]>; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected] Hi, The Commitfest 2022-11 status still shows as "In Progress", Shouldn't the status be changed to "Closed" and the entries be moved to the next commitfest. Regards, Vignesh On Wed, 16 Nov 2022 at 18:30, Ian Lawrence Barwick <[email protected]> wrote: > > 2022年11月14日(月) 22:38 Ian Lawrence Barwick <[email protected]>: > > > > 2022年11月14日(月) 22:23 James Coleman <[email protected]>: > > > > > > On Mon, Nov 14, 2022 at 7:08 AM Ian Lawrence Barwick <[email protected]> wrote: > > > > > > > > 2022年11月9日(水) 8:12 Justin Pryzby <[email protected]>: > > > .... > > > > > If my script is not wrong, these patches add TAP tests, but don't update > > > > > the requisite ./meson.build file. It seems like it'd be reasonable to > > > > > set them all as WOA until that's done. > > > > > > > > > > $ for a in `git branch -a |sort |grep commitfest/40`; do : echo "$a..."; x=`git log -1 --compact-summary "$a"`; echo "$x" |grep '/t/.*pl.*new' >/dev/null || continue; echo "$x" |grep -Fw meson >/dev/null && continue; git log -1 --oneline "$a"; done > > > > > ... [CF 40/3558] Allow file inclusion in pg_hba and pg_ident files > > > > > ... [CF 40/3628] Teach pg_waldump to extract FPIs from the WAL stream > > > > > ... [CF 40/3646] Skip replicating the tables specified in except table option > > > > > ... [CF 40/3663] Switching XLog source from archive to streaming when primary available > > > > > ... [CF 40/3670] pg_rewind: warn when checkpoint hasn't happened after promotion > > > > > ... [CF 40/3729] Testing autovacuum wraparound > > > > > ... [CF 40/3877] vacuumlo: add test to vacuumlo for test coverage > > > > > ... [CF 40/3985] TDE key management patches > > > > > > > > Looks like your script is correct, will update accordingly. > > > > > > > > > > It's possible this has been discussed before, but it seems less than > > > ideal to have notifications about moving to WOA be sent only in a bulk > > > email hanging off the "current CF" email chain as opposed to being > > > sent to the individual threads. Perhaps that's something the app > > > should do for us in this situation. Without that though the patch > > > authors are left to wade through unrelated discussion, and, probably > > > more importantly, the patch discussion thread doesn't show the current > > > state (I think bumping there is more likely to prompt activity as > > > well). > > > > FWIW I've been manually "bumping" the respective threads, which is somewhat > > time-consuming but seems to have been quite productive in terms of getting > > patches updated. > > > > Will do same for the above once I've confirmed what is being requested, > > (which I presume is adding the new tests to the 'tests' array in the respective > > "meson.build" file; just taking the opportunity to familiariize myself with it). > > Various mails since sent to the appropriate threads; I took the opportunity > to create a short wiki page: > > https://wiki.postgresql.org/wiki/Meson_for_patch_authors > > with relevant details (AFAICS) for anyone not familiar with meson; corrections/ > improvements welcome. > > In the meantime I notice a number of patches in cfbot are currently failing on > TAP test "test_custom_rmgrs/t/001_basic.pl" in some environments. This was > added the other day in commit ae168c794f; there is already a fix for the issue > ( 36e0358e70 ) but the cfbot doesn't have that commit yet. > > Regards > > Ian Barwick ^ permalink raw reply [nested|flat] 29+ messages in thread
* Re: Commit fest 2022-11 @ 2022-12-07 03:20 Michael Paquier <[email protected]> parent: vignesh C <[email protected]> 0 siblings, 0 replies; 29+ messages in thread From: Michael Paquier @ 2022-12-07 03:20 UTC (permalink / raw) To: vignesh C <[email protected]>; +Cc: Ian Lawrence Barwick <[email protected]>; James Coleman <[email protected]>; Justin Pryzby <[email protected]>; Greg Stark <[email protected]>; Simon Riggs <[email protected]>; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected] On Wed, Dec 07, 2022 at 08:25:25AM +0530, vignesh C wrote: > The Commitfest 2022-11 status still shows as "In Progress", Shouldn't > the status be changed to "Closed" and the entries be moved to the next > commitfest. Yes, Ian has told me that he is on it this week. -- Michael Attachments: [application/pgp-signature] signature.asc (833B, ../../[email protected]/2-signature.asc) download ^ permalink raw reply [nested|flat] 29+ messages in thread
* [PATCH v20 4/6] Move conversion of a "historic" to MVCC snapshot to a separate function. @ 2025-08-11 13:23 Antonin Houska <[email protected]> 0 siblings, 0 replies; 29+ messages in thread From: Antonin Houska @ 2025-08-11 13:23 UTC (permalink / raw) The conversion is now handled by SnapBuildMVCCFromHistoric(). REPACK CONCURRENTLY will also need it. --- src/backend/replication/logical/snapbuild.c | 51 +++++++++++++++++---- src/backend/utils/time/snapmgr.c | 3 +- src/include/replication/snapbuild.h | 1 + src/include/utils/snapmgr.h | 1 + 4 files changed, 45 insertions(+), 11 deletions(-) diff --git a/src/backend/replication/logical/snapbuild.c b/src/backend/replication/logical/snapbuild.c index 98ddee20929..a2f1803622c 100644 --- a/src/backend/replication/logical/snapbuild.c +++ b/src/backend/replication/logical/snapbuild.c @@ -440,10 +440,7 @@ Snapshot SnapBuildInitialSnapshot(SnapBuild *builder) { Snapshot snap; - TransactionId xid; TransactionId safeXid; - TransactionId *newxip; - int newxcnt = 0; Assert(XactIsoLevel == XACT_REPEATABLE_READ); Assert(builder->building_full_snapshot); @@ -485,6 +482,31 @@ SnapBuildInitialSnapshot(SnapBuild *builder) MyProc->xmin = snap->xmin; + /* Convert the historic snapshot to MVCC snapshot. */ + return SnapBuildMVCCFromHistoric(snap, true); +} + +/* + * Turn a historic MVCC snapshot into an ordinary MVCC snapshot. + * + * Unlike a regular (non-historic) MVCC snapshot, the xip array of this + * snapshot contains not only running main transactions, but also their + * subtransactions. This difference does has no impact on XidInMVCCSnapshot(). + * + * Pass true for 'in_place' if you don't care about modifying the source + * snapshot. If you need a new instance, and one that was allocated as a + * single chunk of memory, pass false. + */ +Snapshot +SnapBuildMVCCFromHistoric(Snapshot snapshot, bool in_place) +{ + TransactionId xid; + TransactionId *oldxip = snapshot->xip; + uint32 oldxcnt = snapshot->xcnt; + TransactionId *newxip; + int newxcnt = 0; + Snapshot result; + /* allocate in transaction context */ newxip = (TransactionId *) palloc(sizeof(TransactionId) * GetMaxSnapshotXidCount()); @@ -495,7 +517,7 @@ SnapBuildInitialSnapshot(SnapBuild *builder) * classical snapshot by marking all non-committed transactions as * in-progress. This can be expensive. */ - for (xid = snap->xmin; NormalTransactionIdPrecedes(xid, snap->xmax);) + for (xid = snapshot->xmin; NormalTransactionIdPrecedes(xid, snapshot->xmax);) { void *test; @@ -503,7 +525,7 @@ SnapBuildInitialSnapshot(SnapBuild *builder) * Check whether transaction committed using the decoding snapshot * meaning of ->xip. */ - test = bsearch(&xid, snap->xip, snap->xcnt, + test = bsearch(&xid, snapshot->xip, snapshot->xcnt, sizeof(TransactionId), xidComparator); if (test == NULL) @@ -520,11 +542,22 @@ SnapBuildInitialSnapshot(SnapBuild *builder) } /* adjust remaining snapshot fields as needed */ - snap->snapshot_type = SNAPSHOT_MVCC; - snap->xcnt = newxcnt; - snap->xip = newxip; + snapshot->xcnt = newxcnt; + snapshot->xip = newxip; - return snap; + if (in_place) + result = snapshot; + else + { + result = CopySnapshot(snapshot); + + /* Restore the original values so the source is intact. */ + snapshot->xip = oldxip; + snapshot->xcnt = oldxcnt; + } + result->snapshot_type = SNAPSHOT_MVCC; + + return result; } /* diff --git a/src/backend/utils/time/snapmgr.c b/src/backend/utils/time/snapmgr.c index 65561cc6bc3..bc7840052fe 100644 --- a/src/backend/utils/time/snapmgr.c +++ b/src/backend/utils/time/snapmgr.c @@ -212,7 +212,6 @@ typedef struct ExportedSnapshot static List *exportedSnapshots = NIL; /* Prototypes for local functions */ -static Snapshot CopySnapshot(Snapshot snapshot); static void UnregisterSnapshotNoOwner(Snapshot snapshot); static void FreeSnapshot(Snapshot snapshot); static void SnapshotResetXmin(void); @@ -602,7 +601,7 @@ SetTransactionSnapshot(Snapshot sourcesnap, VirtualTransactionId *sourcevxid, * The copy is palloc'd in TopTransactionContext and has initial refcounts set * to 0. The returned snapshot has the copied flag set. */ -static Snapshot +Snapshot CopySnapshot(Snapshot snapshot) { Snapshot newsnap; diff --git a/src/include/replication/snapbuild.h b/src/include/replication/snapbuild.h index 44031dcf6e3..6d4d2d1814c 100644 --- a/src/include/replication/snapbuild.h +++ b/src/include/replication/snapbuild.h @@ -73,6 +73,7 @@ extern void FreeSnapshotBuilder(SnapBuild *builder); extern void SnapBuildSnapDecRefcount(Snapshot snap); extern Snapshot SnapBuildInitialSnapshot(SnapBuild *builder); +extern Snapshot SnapBuildMVCCFromHistoric(Snapshot snapshot, bool in_place); extern const char *SnapBuildExportSnapshot(SnapBuild *builder); extern void SnapBuildClearExportedSnapshot(void); extern void SnapBuildResetExportedSnapshotState(void); diff --git a/src/include/utils/snapmgr.h b/src/include/utils/snapmgr.h index 604c1f90216..f65f83c85cd 100644 --- a/src/include/utils/snapmgr.h +++ b/src/include/utils/snapmgr.h @@ -63,6 +63,7 @@ extern Snapshot GetTransactionSnapshot(void); extern Snapshot GetLatestSnapshot(void); extern void SnapshotSetCommandId(CommandId curcid); +extern Snapshot CopySnapshot(Snapshot snapshot); extern Snapshot GetCatalogSnapshot(Oid relid); extern Snapshot GetNonHistoricCatalogSnapshot(Oid relid); extern void InvalidateCatalogSnapshot(void); -- 2.39.5 --3q6txozlgl6t37td Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="v20-0005-Add-CONCURRENTLY-option-to-REPACK-command.patch" ^ permalink raw reply [nested|flat] 29+ messages in thread
end of thread, other threads:[~2025-08-11 13:23 UTC | newest] Thread overview: 29+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2020-03-13 07:59 [PATCH v49 3/7] Make archiver process an auxiliary process Kyotaro Horiguchi <[email protected]> 2022-10-31 05:42 Commit fest 2022-11 Michael Paquier <[email protected]> 2022-11-01 01:01 ` Re: Commit fest 2022-11 Ian Lawrence Barwick <[email protected]> 2022-11-01 04:26 ` Re: Commit fest 2022-11 jian he <[email protected]> 2022-11-01 04:35 ` Re: Commit fest 2022-11 Michael Paquier <[email protected]> 2022-11-01 04:40 ` Re: Commit fest 2022-11 Michael Paquier <[email protected]> 2022-11-01 10:10 ` Re: Commit fest 2022-11 Ian Lawrence Barwick <[email protected]> 2022-11-01 10:59 ` Re: Commit fest 2022-11 Michael Paquier <[email protected]> 2022-11-01 16:36 ` Re: Commit fest 2022-11 Magnus Hagander <[email protected]> 2022-11-01 23:21 ` Re: Commit fest 2022-11 Ian Lawrence Barwick <[email protected]> 2022-11-01 08:59 ` Re: Commit fest 2022-11 Simon Riggs <[email protected]> 2022-11-01 10:15 ` Re: Commit fest 2022-11 Ian Lawrence Barwick <[email protected]> 2022-11-01 10:55 ` Re: Commit fest 2022-11 Michael Paquier <[email protected]> 2022-11-02 10:10 ` Re: Commit fest 2022-11 Greg Stark <[email protected]> 2022-11-03 02:33 ` Re: Commit fest 2022-11 Ian Lawrence Barwick <[email protected]> 2022-11-03 09:48 ` Re: Commit fest 2022-11 Ian Lawrence Barwick <[email protected]> 2022-11-03 11:58 ` Re: Commit fest 2022-11 Michael Paquier <[email protected]> 2022-11-04 00:43 ` Re: Commit fest 2022-11 Justin Pryzby <[email protected]> 2022-11-04 01:23 ` Re: Commit fest 2022-11 Ian Lawrence Barwick <[email protected]> 2022-11-04 05:18 ` Re: Commit fest 2022-11 Ian Lawrence Barwick <[email protected]> 2022-11-04 20:18 ` Re: Commit fest 2022-11 Jacob Champion <[email protected]> 2022-11-08 23:12 ` Re: Commit fest 2022-11 Justin Pryzby <[email protected]> 2022-11-14 12:08 ` Re: Commit fest 2022-11 Ian Lawrence Barwick <[email protected]> 2022-11-14 13:23 ` Re: Commit fest 2022-11 James Coleman <[email protected]> 2022-11-14 13:38 ` Re: Commit fest 2022-11 Ian Lawrence Barwick <[email protected]> 2022-11-16 13:00 ` Re: Commit fest 2022-11 Ian Lawrence Barwick <[email protected]> 2022-12-07 02:55 ` Re: Commit fest 2022-11 vignesh C <[email protected]> 2022-12-07 03:20 ` Re: Commit fest 2022-11 Michael Paquier <[email protected]> 2025-08-11 13:23 [PATCH v20 4/6] Move conversion of a "historic" to MVCC snapshot to a separate function. Antonin Houska <[email protected]>
This inbox is served by agora; see mirroring instructions for how to clone and mirror all data and code used for this inbox