public inbox for [email protected]
help / color / mirror / Atom feed[PATCH v5 3/3] Move code to apply one WAL record to a subroutine.
13+ messages / 3 participants
[nested] [flat]
* [PATCH v5 3/3] Move code to apply one WAL record to a subroutine.
@ 2021-07-31 12:06 Heikki Linnakangas <[email protected]>
0 siblings, 0 replies; 13+ messages in thread
From: Heikki Linnakangas @ 2021-07-31 12:06 UTC (permalink / raw)
---
src/backend/access/transam/xlogrecovery.c | 283 +++++++++++-----------
1 file changed, 148 insertions(+), 135 deletions(-)
diff --git a/src/backend/access/transam/xlogrecovery.c b/src/backend/access/transam/xlogrecovery.c
index 6030d6fe819..85909c9b686 100644
--- a/src/backend/access/transam/xlogrecovery.c
+++ b/src/backend/access/transam/xlogrecovery.c
@@ -366,6 +366,7 @@ static char recoveryStopName[MAXFNAMELEN];
static bool recoveryStopAfter;
/* prototypes for local functions */
+static void ApplyWalRecord(XLogReaderState *xlogreader, XLogRecord *record);
static void xlog_block_info(StringInfo buf, XLogReaderState *record);
static void readRecoverySignalFile(void);
@@ -1374,11 +1375,8 @@ PerformWalRecovery(void)
if (record != NULL)
{
- ErrorContextCallback errcallback;
TimestampTz xtime;
PGRUsage ru0;
- XLogRecPtr ReadRecPtr;
- XLogRecPtr EndRecPtr;
pg_rusage_init(&ru0);
@@ -1400,11 +1398,6 @@ PerformWalRecovery(void)
*/
do
{
- bool switchedTLI = false;
-
- ReadRecPtr = xlogreader->ReadRecPtr;
- EndRecPtr = xlogreader->EndRecPtr;
-
#ifdef WAL_DEBUG
if (XLOG_DEBUG ||
(rmid == RM_XACT_ID && trace_recovery_messages <= DEBUG2) ||
@@ -1414,8 +1407,8 @@ PerformWalRecovery(void)
initStringInfo(&buf);
appendStringInfo(&buf, "REDO @ %X/%X; LSN %X/%X: ",
- LSN_FORMAT_ARGS(ReadRecPtr),
- LSN_FORMAT_ARGS(EndRecPtr));
+ LSN_FORMAT_ARGS(xlogreader->ReadRecPtr),
+ LSN_FORMAT_ARGS(xlogreader->EndRecPtr));
xlog_outrec(&buf, xlogreader);
appendStringInfoString(&buf, " - ");
xlog_outdesc(&buf, xlogreader);
@@ -1470,132 +1463,10 @@ PerformWalRecovery(void)
recoveryPausesHere(false);
}
- /* Setup error traceback support for ereport() */
- errcallback.callback = rm_redo_error_callback;
- errcallback.arg = (void *) xlogreader;
- errcallback.previous = error_context_stack;
- error_context_stack = &errcallback;
-
/*
- * ShmemVariableCache->nextXid must be beyond record's xid.
+ * Apply the record
*/
- AdvanceNextFullTransactionIdPastXid(record->xl_xid);
-
- /*
- * Before replaying this record, check if this record causes the
- * current timeline to change. The record is already considered to
- * be part of the new timeline, so we update ThisTimeLineID before
- * replaying it. That's important so that replayEndTLI, which is
- * recorded as the minimum recovery point's TLI if recovery stops
- * after this record, is set correctly.
- */
- if (record->xl_rmid == RM_XLOG_ID)
- {
- TimeLineID newTLI = ThisTimeLineID;
- TimeLineID prevTLI = ThisTimeLineID;
- uint8 info = record->xl_info & ~XLR_INFO_MASK;
-
- if (info == XLOG_CHECKPOINT_SHUTDOWN)
- {
- CheckPoint checkPoint;
-
- memcpy(&checkPoint, XLogRecGetData(xlogreader), sizeof(CheckPoint));
- newTLI = checkPoint.ThisTimeLineID;
- prevTLI = checkPoint.PrevTimeLineID;
- }
- else if (info == XLOG_END_OF_RECOVERY)
- {
- xl_end_of_recovery xlrec;
-
- memcpy(&xlrec, XLogRecGetData(xlogreader), sizeof(xl_end_of_recovery));
- newTLI = xlrec.ThisTimeLineID;
- prevTLI = xlrec.PrevTimeLineID;
- }
-
- if (newTLI != ThisTimeLineID)
- {
- /* Check that it's OK to switch to this TLI */
- checkTimeLineSwitch(EndRecPtr, newTLI, prevTLI);
-
- /* Following WAL records should be run with new TLI */
- ThisTimeLineID = newTLI;
- switchedTLI = true;
- }
- }
-
- /*
- * Update shared replayEndRecPtr before replaying this record, so
- * that XLogFlush will update minRecoveryPoint correctly.
- */
- SpinLockAcquire(&XLogRecCtl->info_lck);
- XLogRecCtl->replayEndRecPtr = EndRecPtr;
- XLogRecCtl->replayEndTLI = ThisTimeLineID;
- SpinLockRelease(&XLogRecCtl->info_lck);
-
- /*
- * If we are attempting to enter Hot Standby mode, process XIDs we
- * see
- */
- if (standbyState >= STANDBY_INITIALIZED &&
- TransactionIdIsValid(record->xl_xid))
- RecordKnownAssignedTransactionIds(record->xl_xid);
-
- /* Now apply the WAL record itself */
- RmgrTable[record->xl_rmid].rm_redo(xlogreader);
-
- /*
- * After redo, check whether the backup pages associated with the
- * WAL record are consistent with the existing pages. This check
- * is done only if consistency check is enabled for this record.
- */
- if ((record->xl_info & XLR_CHECK_CONSISTENCY) != 0)
- checkXLogConsistency(xlogreader);
-
- /* Pop the error context stack */
- error_context_stack = errcallback.previous;
-
- /*
- * Update lastReplayedEndRecPtr after this record has been
- * successfully replayed.
- */
- SpinLockAcquire(&XLogRecCtl->info_lck);
- XLogRecCtl->lastReplayedEndRecPtr = EndRecPtr;
- XLogRecCtl->lastReplayedTLI = ThisTimeLineID;
- SpinLockRelease(&XLogRecCtl->info_lck);
-
- /* Also remember its starting position. */
- LastReplayedReadRecPtr = ReadRecPtr;
-
- /*
- * If rm_redo called XLogRequestWalReceiverReply, then we wake up
- * the receiver so that it notices the updated
- * lastReplayedEndRecPtr and sends a reply to the primary.
- */
- if (doRequestWalReceiverReply)
- {
- doRequestWalReceiverReply = false;
- WalRcvForceReply();
- }
-
- /* Allow read-only connections if we're consistent now */
- CheckRecoveryConsistency();
-
- /* Is this a timeline switch? */
- if (switchedTLI)
- {
- /*
- * Before we continue on the new timeline, clean up any
- * (possibly bogus) future WAL segments on the old timeline.
- */
- RemoveNonParentXlogFiles(EndRecPtr, ThisTimeLineID);
-
- /*
- * Wake up any walsenders to notice that we are on a new
- * timeline.
- */
- if (AllowCascadeReplication())
- WalSndWakeup();
- }
+ ApplyWalRecord(xlogreader, record);
/* Exit loop if we reached inclusive recovery target */
if (recoveryStopsAfter(xlogreader))
@@ -1654,7 +1525,7 @@ PerformWalRecovery(void)
ereport(LOG,
(errmsg("redo done at %X/%X system usage: %s",
- LSN_FORMAT_ARGS(ReadRecPtr),
+ LSN_FORMAT_ARGS(xlogreader->ReadRecPtr),
pg_rusage_show(&ru0))));
xtime = GetLatestXTime();
if (xtime)
@@ -1683,6 +1554,148 @@ PerformWalRecovery(void)
(errmsg("recovery ended before configured recovery target was reached")));
}
+/*
+ * Subroutine of PerformWalRecovery, to apply one WAL record.
+ */
+static void
+ApplyWalRecord(XLogReaderState *xlogreader, XLogRecord *record)
+{
+ XLogRecPtr ReadRecPtr;
+ XLogRecPtr EndRecPtr;
+ ErrorContextCallback errcallback;
+ bool switchedTLI = false;
+
+ ReadRecPtr = xlogreader->ReadRecPtr;
+ EndRecPtr = xlogreader->EndRecPtr;
+
+ /* Setup error traceback support for ereport() */
+ errcallback.callback = rm_redo_error_callback;
+ errcallback.arg = (void *) xlogreader;
+ errcallback.previous = error_context_stack;
+ error_context_stack = &errcallback;
+
+ /*
+ * ShmemVariableCache->nextXid must be beyond record's xid.
+ */
+ AdvanceNextFullTransactionIdPastXid(record->xl_xid);
+
+ /*
+ * Before replaying this record, check if this record causes the
+ * current timeline to change. The record is already considered to
+ * be part of the new timeline, so we update ThisTimeLineID before
+ * replaying it. That's important so that replayEndTLI, which is
+ * recorded as the minimum recovery point's TLI if recovery stops
+ * after this record, is set correctly.
+ */
+ if (record->xl_rmid == RM_XLOG_ID)
+ {
+ TimeLineID newTLI = ThisTimeLineID;
+ TimeLineID prevTLI = ThisTimeLineID;
+ uint8 info = record->xl_info & ~XLR_INFO_MASK;
+
+ if (info == XLOG_CHECKPOINT_SHUTDOWN)
+ {
+ CheckPoint checkPoint;
+
+ memcpy(&checkPoint, XLogRecGetData(xlogreader), sizeof(CheckPoint));
+ newTLI = checkPoint.ThisTimeLineID;
+ prevTLI = checkPoint.PrevTimeLineID;
+ }
+ else if (info == XLOG_END_OF_RECOVERY)
+ {
+ xl_end_of_recovery xlrec;
+
+ memcpy(&xlrec, XLogRecGetData(xlogreader), sizeof(xl_end_of_recovery));
+ newTLI = xlrec.ThisTimeLineID;
+ prevTLI = xlrec.PrevTimeLineID;
+ }
+
+ if (newTLI != ThisTimeLineID)
+ {
+ /* Check that it's OK to switch to this TLI */
+ checkTimeLineSwitch(EndRecPtr, newTLI, prevTLI);
+
+ /* Following WAL records should be run with new TLI */
+ ThisTimeLineID = newTLI;
+ switchedTLI = true;
+ }
+ }
+
+ /*
+ * Update shared replayEndRecPtr before replaying this record, so
+ * that XLogFlush will update minRecoveryPoint correctly.
+ */
+ SpinLockAcquire(&XLogRecCtl->info_lck);
+ XLogRecCtl->replayEndRecPtr = EndRecPtr;
+ XLogRecCtl->replayEndTLI = ThisTimeLineID;
+ SpinLockRelease(&XLogRecCtl->info_lck);
+
+ /*
+ * If we are attempting to enter Hot Standby mode, process XIDs we
+ * see
+ */
+ if (standbyState >= STANDBY_INITIALIZED &&
+ TransactionIdIsValid(record->xl_xid))
+ RecordKnownAssignedTransactionIds(record->xl_xid);
+
+ /* Now apply the WAL record itself */
+ RmgrTable[record->xl_rmid].rm_redo(xlogreader);
+
+ /*
+ * After redo, check whether the backup pages associated with the
+ * WAL record are consistent with the existing pages. This check
+ * is done only if consistency check is enabled for this record.
+ */
+ if ((record->xl_info & XLR_CHECK_CONSISTENCY) != 0)
+ checkXLogConsistency(xlogreader);
+
+ /* Pop the error context stack */
+ error_context_stack = errcallback.previous;
+
+ /*
+ * Update lastReplayedEndRecPtr after this record has been
+ * successfully replayed.
+ */
+ SpinLockAcquire(&XLogRecCtl->info_lck);
+ XLogRecCtl->lastReplayedEndRecPtr = EndRecPtr;
+ XLogRecCtl->lastReplayedTLI = ThisTimeLineID;
+ SpinLockRelease(&XLogRecCtl->info_lck);
+
+ /* Also remember its starting position. */
+ LastReplayedReadRecPtr = ReadRecPtr;
+
+ /*
+ * If rm_redo called XLogRequestWalReceiverReply, then we wake up
+ * the receiver so that it notices the updated
+ * lastReplayedEndRecPtr and sends a reply to the primary.
+ */
+ if (doRequestWalReceiverReply)
+ {
+ doRequestWalReceiverReply = false;
+ WalRcvForceReply();
+ }
+
+ /* Allow read-only connections if we're consistent now */
+ CheckRecoveryConsistency();
+
+ /* Is this a timeline switch? */
+ if (switchedTLI)
+ {
+ /*
+ * Before we continue on the new timeline, clean up any
+ * (possibly bogus) future WAL segments on the old timeline.
+ */
+ RemoveNonParentXlogFiles(EndRecPtr, ThisTimeLineID);
+
+ /*
+ * Wake up any walsenders to notice that we are on a new
+ * timeline.
+ */
+ if (AllowCascadeReplication())
+ WalSndWakeup();
+ }
+}
+
/*
* Error context callback for errors occurring during rm_redo().
*/
--
2.30.2
--------------F589ECF1004AF34308A0B206--
^ permalink raw reply [nested|flat] 13+ messages in thread
* Commit fest 2025-03
@ 2025-02-25 16:19 vignesh C <[email protected]>
0 siblings, 1 reply; 13+ messages in thread
From: vignesh C @ 2025-02-25 16:19 UTC (permalink / raw)
To: PostgreSQL Hackers <[email protected]>
Hi Everyone,
The next PostgreSQL CommitFest is starting in a few days, and I wanted
to remind everyone to register their patches to ensure they receive
the necessary attention and feedback. I've noticed that a few patches
are currently unregistered. If you're still evaluating a POC or
finalizing the design, you can choose to add it later. However, if a
patch is in good shape for review, I encourage you to register it now
to maximize its chances of getting feedback.
Here are few patches that I felt is not unregistered:
1) Federated Authn/z with OAUTHBEARER - Author - Daniel Gustafsson
https://www.postgresql.org/message-id/flat/d1b467a78e0e36ed85a09adf979d04cf124a9d4b.camel%40vmware.c...
2) Update docs for UUID data type - Author - Andy Alsup
https://www.postgresql.org/message-id/flat/64b18b5cf27cf13237aec6c9fbbf7720c7107419.camel%40cybertec...
3) Lock-free XLog Reservation from WAL - Author - Zhiguo
https://www.postgresql.org/message-id/flat/PH7PR11MB5796659F654F9BE983F3AD97EF142%40PH7PR11MB5796.na...
4) Restrict copying of invalidated replication slots - Author - Shlok Kyal
https://www.postgresql.org/message-id/flat/CANhcyEU65aH0VYnLiu%3DOhNNxhnhNhwcXBeT-jvRe1OiJTo_Ayg%40m...
5) MAX_BACKENDS size (comment accuracy) - Author - Jacob Brazeal
https://www.postgresql.org/message-id/CA%2BCOZaBO_s3LfALq%3Db%2BHcBHFSOEGiApVjrRacCe4VP9m7CJsNQ%40ma...
6) Simplify the logic a bit (src/bin/scripts/reindexdb.c)- Author -
Ranier Vilela
https://www.postgresql.org/message-id/[email protected]...
7) ReplicationSlotRelease() crashes when the instance is in the single
user mode - Author - Hayato Kuroda
https://www.postgresql.org/message-id/flat/OSCPR01MB14966ED588A0328DAEBE8CB25F5FA2%40OSCPR01MB14966....
8) long-standing data loss bug in initial sync of logical replication
- Author - Shlok Kyal
https://www.postgresql.org/message-id/CANhcyEXvcwHE54UEnatUKEs7v6jwRQQi_4qC64ngCfw1zTd5hg%40mail.gma...
If any of these are ready, please add them to the CommitFest page. If
you think some are trivial and don’t need to be added, that’s fine
too.
Looking forward to a productive CommitFest!
Regards,
Vignesh
^ permalink raw reply [nested|flat] 13+ messages in thread
* Re: Commit fest 2025-03
@ 2025-03-03 09:32 vignesh C <[email protected]>
parent: vignesh C <[email protected]>
0 siblings, 2 replies; 13+ messages in thread
From: vignesh C @ 2025-03-03 09:32 UTC (permalink / raw)
To: PostgreSQL Hackers <[email protected]>
On Tue, 25 Feb 2025 at 21:49, vignesh C <[email protected]> wrote:
>
> If any of these are ready, please add them to the CommitFest page. If
> you think some are trivial and don’t need to be added, that’s fine
> too.
> Looking forward to a productive CommitFest!
March 2025 commitfest has started, the current status is:
status | start
--------------------------------+-----------
Needs review: | 198
Waiting on Author: | 37
Ready for Committer: | 33
Committed: | 52
Moved to next CF | 7
Withdrawn: | 12
Rejected: | 1
Returned with Feedback: | 2
Total: | 342
I will be having a look at the commitfest entries, correcting the
status if any of them need to be corrected and update the authors.
Kindly keep the patch updated so that the reviewers/committers can
review the patches and get it committed.
Regards,
Vignesh
^ permalink raw reply [nested|flat] 13+ messages in thread
* Re: Commit fest 2025-03
@ 2025-03-05 09:22 vignesh C <[email protected]>
parent: vignesh C <[email protected]>
1 sibling, 1 reply; 13+ messages in thread
From: vignesh C @ 2025-03-05 09:22 UTC (permalink / raw)
To: PostgreSQL Hackers <[email protected]>
On Mon, 3 Mar 2025 at 15:02, vignesh C <[email protected]> wrote:
>
> I will be having a look at the commitfest entries, correcting the
> status if any of them need to be corrected and update the authors.
> Kindly keep the patch updated so that the reviewers/committers can
> review the patches and get it committed.
The following "Needs review" patches need rebase
---------------------------------------
Incorrect result of bitmap heap scan. - Matthias van de Meent
Document hostssl related concepts better - David Johnston
noreturn attribute for MSVC, C11 - Peter Eisentraut
Enhance file_fdw to report processed and skipped tuples in COPY
progress - Fujii Masao
Logging plan of the currently running query - Atsushi Torikoshi
Index Prefetching - Tomas Vondra
[CREATE|RE] INDEX CONCURRENTLY with single heap scan and short-term
resetting shapshots - Michail Nikolaev
Allow partition-wise join when whole row var is needed - Ashutosh
Bapat, Alexander Pyhalov
Asynchronous MergeAppend Execution - Alexander Pyhalov
Limiting overshoot in nbtree SAOP parallel index scans - Matthias van de Meent
Use read_stream in index vacuum - Andrey Borodin
Adding compression of temporary files - Filip Januš
Allow to use an index for ILIKE in more cases - Yugo Nagata
Use Bump allocator for HashAgg - Jeff Davis
Read stream scalability improvements and AIO-compatibility - Thomas Munro
Compress big WAL records - Andrey Borodin
Use XLOG_CONTROL_FILE macro everywhere - Anton Melnikov
Don't dirty pages while they are getting flushed out - Andres Freund
Enable logical decoding when wal_level = 'replica' without a server
restart - Masahiko Sawada
Logical replication timeout - Shlok Kyal
COPY ON_ERROR 'NULL' - jian he
Changing shared_buffers without restart - Dmitry Dolgov
speedup COPY TO for partitioned table - Jian He
Proposal: Progressive explain - Rafael Castro
Extensible storage manager API - Andreas Karlsson/Anastasia
Lubennikova/Matthias van de Meent/ Tristan Partin
Introduce the ability to enable/disable indexes using ALTER INDEX -
Shayon Mukherjee
general purpose array_sort - Zhao Junwang
explain plans for foreign servers - Dinesh Salve
Allow CI to only run the compiler warnings task - Bertrand Drouvot
Add NetBSD and OpenBSD OSes to Postgres CI - Nazir Bilal Yavuz
The following "Ready for committer" patches needs rebase
---------------------------------------
Truncate logs by max_log_size - Kirill Gavrilov
Patch owners, please provide a rebased version to prepare it for
reviewers and committers.
Regards,
Vignesh
^ permalink raw reply [nested|flat] 13+ messages in thread
* Re: Commit fest 2025-03
@ 2025-03-05 11:20 Jim Jones <[email protected]>
parent: vignesh C <[email protected]>
0 siblings, 2 replies; 13+ messages in thread
From: Jim Jones @ 2025-03-05 11:20 UTC (permalink / raw)
To: vignesh C <[email protected]>; PostgreSQL Hackers <[email protected]>
Hi Vignesh
On 05.03.25 10:22, vignesh C wrote:
> The following "Ready for committer" patches needs rebase
> ---------------------------------------
> Truncate logs by max_log_size - Kirill Gavrilov
>
> Patch owners, please provide a rebased version to prepare it for
> reviewers and committers.
Is there something wrong with the commitfest app? This patch applies
cleanly and passes all tests
Best, Jim
^ permalink raw reply [nested|flat] 13+ messages in thread
* Re: Commit fest 2025-03
@ 2025-03-06 15:38 vignesh C <[email protected]>
parent: Jim Jones <[email protected]>
1 sibling, 0 replies; 13+ messages in thread
From: vignesh C @ 2025-03-06 15:38 UTC (permalink / raw)
To: Jim Jones <[email protected]>; +Cc: PostgreSQL Hackers <[email protected]>
On Wed, 5 Mar 2025 at 16:50, Jim Jones <[email protected]> wrote:
>
> Hi Vignesh
>
> On 05.03.25 10:22, vignesh C wrote:
> > The following "Ready for committer" patches needs rebase
> > ---------------------------------------
> > Truncate logs by max_log_size - Kirill Gavrilov
> >
> > Patch owners, please provide a rebased version to prepare it for
> > reviewers and committers.
>
> Is there something wrong with the commitfest app? This patch applies
> cleanly and passes all tests
I verified that it applies neatly and passes the tests for me too, I
have reported this issue at [1]. I don't know the reason for this.
Let's see if we get any response from the other thread.
[1] - https://www.postgresql.org/message-id/CALDaNm3ta7UV_eD%2BObgVsivGgPZSj1YqnO4-ojeBz10J95u7_A%40mail.g...
Regards,
Vignesh
^ permalink raw reply [nested|flat] 13+ messages in thread
* Re: Commit fest 2025-03
@ 2025-03-09 12:10 vignesh C <[email protected]>
parent: Jim Jones <[email protected]>
1 sibling, 0 replies; 13+ messages in thread
From: vignesh C @ 2025-03-09 12:10 UTC (permalink / raw)
To: Jim Jones <[email protected]>; +Cc: PostgreSQL Hackers <[email protected]>
On Wed, 5 Mar 2025 at 16:50, Jim Jones <[email protected]> wrote:
>
> Hi Vignesh
>
> On 05.03.25 10:22, vignesh C wrote:
> > The following "Ready for committer" patches needs rebase
> > ---------------------------------------
> > Truncate logs by max_log_size - Kirill Gavrilov
> >
> > Patch owners, please provide a rebased version to prepare it for
> > reviewers and committers.
>
> Is there something wrong with the commitfest app? This patch applies
> cleanly and passes all tests
This issue has been addressed now, here are the updated patches that
needs to be rebased:
The walsender does not update its IO statistics until it exits -
Bertrand Drouvot
noreturn attribute for MSVC, C11 - Peter Eisentraut
Add pg_stat_session - Sergey Dudoladov
Logging plan of the currently running query - Atsushi Torikoshi
Index Prefetching - Tomas Vondra
Allow partition-wise join when whole row var is needed - Alexander Pyhalov
Asynchronous MergeAppend Execution - Alexander Pyhalov
AIO - Andres Freund
Limiting overshoot in nbtree SAOP parallel index scans - Matthias van de Meent
Use read_stream in index vacuum - Andrey Borodin
Adding compression of temporary files - Filip Janus
Allow to use an index for ILIKE in more cases - Yugo NAGATA
Use Bump allocator for HashAgg - Jeff Davis
Read stream scalability improvements and AIO-compatibility - Thomas Munro
Compress big WAL records - Andrey Borodin
Reduce timing overhead of EXPLAIN ANALYZE using rdtsc - Lukas Fittl
Use XLOG_CONTROL_FILE macro everywhere - Anton A. Melnikov
Don't dirty pages while they are getting flushed out - Andres Freund
Enable logical decoding when wal_level = 'replica' without a server
restart - Masahiko Sawada
VACUUM FULL / CLUSTER CONCURRENTLY - Antonin Houska
NOT ENFORCED constraint feature - Amul Sul
Changing shared_buffers without restart - Ashutosh Bapat
Extended Statistics set/restore/clear functions - Corey Huinker
general purpose array_sort - jian he
explain plans for foreign servers - Dinesh Salve
Enable fine-grained control over what gets logged on connection
attempt (reduces log size) - Sergey
Allow CI to only run the compiler warnings task - Bertrand Drouvot
Patch owners, please provide a rebased version to prepare it for
reviewers and committers.
Regards,
Vignesh
^ permalink raw reply [nested|flat] 13+ messages in thread
* Re: Commit fest 2025-03
@ 2025-03-11 04:11 vignesh C <[email protected]>
parent: vignesh C <[email protected]>
1 sibling, 1 reply; 13+ messages in thread
From: vignesh C @ 2025-03-11 04:11 UTC (permalink / raw)
To: PostgreSQL Hackers <[email protected]>
On Mon, 3 Mar 2025 at 15:02, vignesh C <[email protected]> wrote:
>
> On Tue, 25 Feb 2025 at 21:49, vignesh C <[email protected]> wrote:
> >
> > If any of these are ready, please add them to the CommitFest page. If
> > you think some are trivial and don’t need to be added, that’s fine
> > too.
> > Looking forward to a productive CommitFest!
>
> March 2025 commitfest has started, the current status is:
> status | start
> --------------------------------+-----------
> Needs review: | 198
> Waiting on Author: | 37
> Ready for Committer: | 33
> Committed: | 52
> Moved to next CF | 7
> Withdrawn: | 12
> Rejected: | 1
> Returned with Feedback: | 2
> Total: | 342
Here's a quick commitfest status report after the first 10 days:
status | start | 10th Mar
----------------------------+--------+----------------
Needs review: | 198 | 182
Waiting on Author: | 37 | 35
Ready for Committer:| 33 | 33
Committed: | 52 | 67
Moved to next CF: | 7 | 7
Withdrawn: | 12 | 15
Rejected: | 1 | 1
RWF: | 2 | 2
Total: | 342 | 342
There are currently 67 patches in the "Ready for Committer" status at
[1]. If any committers have bandwidth, please consider reviewing and
advancing them.
If you have submitted a patch that is in the "Waiting for Author"
state, please update it to "Needs Review" as soon as possible. This is
where reviewers are most likely to focus their efforts. There are 35
patches currently in this state that require updates at [2].
Additionally, 26 patches require a rebase due to recent commits at
[3]. Patch owners are requested to rebase and submit updated versions.
I will be changing the status of these patches to "Waiting on Author",
so please post a rebased version and update the status accordingly.
[1] - https://commitfest.postgresql.org/52/?status=3
[2] - https://commitfest.postgresql.org/52/?status=2
[3] - https://commitfest.postgresql.org/52/?status=1
Regards,
Vignesh
^ permalink raw reply [nested|flat] 13+ messages in thread
* Re: Commit fest 2025-03
@ 2025-03-17 03:56 vignesh C <[email protected]>
parent: vignesh C <[email protected]>
0 siblings, 1 reply; 13+ messages in thread
From: vignesh C @ 2025-03-17 03:56 UTC (permalink / raw)
To: PostgreSQL Hackers <[email protected]>
On Tue, 11 Mar 2025 at 09:41, vignesh C <[email protected]> wrote:
>
Here's a quick commitfest status report as of today:
status | start | 10th | 17th
----------------------------+---------+---------+---------
Needs review: | 198 | 182 | 134
Waiting on Author: | 37 | 35 | 69
Ready for Committer:| 33 | 33 | 34
Committed: | 52 | 67 | 75
Moved to next CF: | 7 | 7 | 11
Withdrawn: | 12 | 15 | 15
Rejected: | 1 | 1 | 3
RWF: | 2 | 2 | 2
Total: | 343 | 343 | 343
Currently, there are 69 patches which are in "Waiting on Author"
status at [1]. Please review the feedback, make the necessary updates,
and move them to "Needs Review" as soon as possible. Additionally, 12
patches require rebasing, as listed in [2]. I am moving these to
"Waiting on Author". Please rebase them and update their status to
"Needs Review". Eight patches have been committed in the last week.
[1] - https://commitfest.postgresql.org/52/?status=2
[2] - https://commitfest.postgresql.org/52/?status=1
Regards,
Vignesh
^ permalink raw reply [nested|flat] 13+ messages in thread
* Re: Commit fest 2025-03
@ 2025-03-24 04:37 vignesh C <[email protected]>
parent: vignesh C <[email protected]>
0 siblings, 1 reply; 13+ messages in thread
From: vignesh C @ 2025-03-24 04:37 UTC (permalink / raw)
To: PostgreSQL Hackers <[email protected]>
On Mon, 17 Mar 2025 at 09:26, vignesh C <[email protected]> wrote:
>
Here's a quick commitfest status report as of today:
status | start | 10th | 17th | 24th
----------------------------+---------+---------+---------+---------
Needs review: | 198 | 182 | 134 | 120
Waiting on Author: | 37 | 35 | 69 | 62
Ready for Committer:| 33 | 33 | 34 | 34
Committed: | 52 | 67 | 75 | 90
Moved to next CF: | 7 | 7 | 11 | 14
Withdrawn: | 12 | 15 | 15 | 18
Rejected: | 1 | 1 | 3 | 3
RWF: | 2 | 2 | 2 | 2
Total: | 343 | 343 | 343 | 343
There are currently 34 patches in the "Ready for Committer" status at
[1]. If any committers have bandwidth, please consider reviewing and
advancing them.
If you have submitted a patch that is in the "Waiting for Author"
state, please update it to "Needs Review" as soon as possible. This is
where reviewers are most likely to focus their efforts. There are 62
patches that are in "Waiting for Author" state at [2]. Additionally,
13 Needs review patches require a rebase due to recent commits at [3].
Patch owners are requested to rebase and submit updated versions.
15 patches have been committed in the last week.
[1] - https://commitfest.postgresql.org/52/?status=3
[2] - https://commitfest.postgresql.org/52/?status=2
[3] - https://commitfest.postgresql.org/52/?status=1
Regards,
Vignesh
^ permalink raw reply [nested|flat] 13+ messages in thread
* Re: Commit fest 2025-03
@ 2025-03-31 03:04 vignesh C <[email protected]>
parent: vignesh C <[email protected]>
0 siblings, 1 reply; 13+ messages in thread
From: vignesh C @ 2025-03-31 03:04 UTC (permalink / raw)
To: PostgreSQL Hackers <[email protected]>
On Mon, 24 Mar 2025 at 10:07, vignesh C <[email protected]> wrote:
>
> On Mon, 17 Mar 2025 at 09:26, vignesh C <[email protected]> wrote:
>
Here's a quick commitfest status report as of today:
status | start | 10th | 17th | 24th | 31st
----------------------------+---------+-------+-------+--------+---------
Needs review: | 198 | 182 | 134 | 120 | 105
Waiting on Author: | 37 | 35 | 69 | 62 | 59
Ready for Committer:| 33 | 33 | 34 | 34 | 27
Committed: | 52 | 67 | 75 | 90 | 109
Moved to next CF: | 7 | 7 | 11 | 14 | 16
Withdrawn: | 12 | 15 | 15 | 18 | 18
Rejected: | 1 | 1 | 3 | 3 | 5
RWF: | 2 | 2 | 2 | 2 | 4
Total: | 343 | 343 | 343 | 343 | 343
There are currently 27 patches in the "Ready for Committer" status at
[1]. If any committers have bandwidth, please consider reviewing and
advancing them. If you have submitted a patch that is in the "Waiting
for Author" state, please update it to "Needs Review" as soon as
possible. This is where reviewers are most likely to focus their
efforts. Additionally, 12 Needs review patches require a rebase due to
recent commits at [2]. Patch owners are requested to rebase and submit
updated versions.
19 patches have been committed in the last week.
[1] - https://commitfest.postgresql.org/52/?status=3
[2] - https://commitfest.postgresql.org/52/?status=1
Regards,
Vignesh
^ permalink raw reply [nested|flat] 13+ messages in thread
* Re: Commit fest 2025-03
@ 2025-04-07 15:07 vignesh C <[email protected]>
parent: vignesh C <[email protected]>
0 siblings, 1 reply; 13+ messages in thread
From: vignesh C @ 2025-04-07 15:07 UTC (permalink / raw)
To: PostgreSQL Hackers <[email protected]>
On Mon, 31 Mar 2025 at 08:34, vignesh C <[email protected]> wrote:
>
> On Mon, 24 Mar 2025 at 10:07, vignesh C <[email protected]> wrote:
Here's a quick commitfest status report as of today:
status | start | 17th | 24th | 31st | 07th
----------------------------+---------+-------+-------+--------+---------
Needs review: | 198 | 134 | 120 | 105 | 64
Waiting on Author: | 37 | 69 | 62 | 59 | 49
Ready for Committer:| 33 | 34 | 34 | 27 | 22
Committed: | 52 | 75 | 90 | 109 | 143
Moved to next CF: | 7 | 11 | 14 | 16 | 30
Withdrawn: | 12 | 15 | 18 | 18 | 22
Rejected: | 1 | 3 | 3 | 5 | 6
RWF: | 2 | 2 | 2 | 4 | 7
Total: | 343 | 343 | 343 | 343 | 343
34 patches were committed in the past week. With only a couple of days
left in this CommitFest, let's focus on committing the patches that
are ready. For those unlikely to make it, we should begin moving them
to the next CommitFest.
Regards,
Vignesh
^ permalink raw reply [nested|flat] 13+ messages in thread
* Re: Commit fest 2025-03
@ 2025-04-09 01:03 vignesh C <[email protected]>
parent: vignesh C <[email protected]>
0 siblings, 0 replies; 13+ messages in thread
From: vignesh C @ 2025-04-09 01:03 UTC (permalink / raw)
To: PostgreSQL Hackers <[email protected]>
On Mon, 7 Apr 2025 at 20:37, vignesh C <[email protected]> wrote:
>
Thanks a lot to all the members who participated in the commitfest.
Here are the final numbers at the end of the commitfest:
status | End of Commitfest
----------------------------+---------------------------
Needs review: | 54
Waiting on Author: | 47
Ready for Committer:| 18
Committed: | 150
Moved to next CF: | 38
Withdrawn: | 22
Rejected: | 6
RWF: | 8
Total: | 343
In comparison to previous March commitfests, we've made remarkable
progress this time by committing an impressive 150 entries.
2025: 150 committed
2024: 131 committed
2023: 127 committed
2022: 98 committed
2021: 122 committed
2020: 90 committed
A special thanks to the reviewers/committers who spent tireless effort
in moving the patches forward.
As per the developer meeting at FOSDEM, patches should only be moved
forward by someone involved in the patch who knows that the patch is
actually being worked on which is mentioned at [1]. So requesting
respective members to move their commitfest entries to the next
commitfest.
[1] - https://www.postgresql.org/message-id/flat/003e3a66-8fcc-4ca0-9e0e-c0afda1c9424%40eisentraut.org
Regards,
Vignesh
^ permalink raw reply [nested|flat] 13+ messages in thread
end of thread, other threads:[~2025-04-09 01:03 UTC | newest]
Thread overview: 13+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2021-07-31 12:06 [PATCH v5 3/3] Move code to apply one WAL record to a subroutine. Heikki Linnakangas <[email protected]>
2025-02-25 16:19 Commit fest 2025-03 vignesh C <[email protected]>
2025-03-03 09:32 ` Re: Commit fest 2025-03 vignesh C <[email protected]>
2025-03-05 09:22 ` Re: Commit fest 2025-03 vignesh C <[email protected]>
2025-03-05 11:20 ` Re: Commit fest 2025-03 Jim Jones <[email protected]>
2025-03-06 15:38 ` Re: Commit fest 2025-03 vignesh C <[email protected]>
2025-03-09 12:10 ` Re: Commit fest 2025-03 vignesh C <[email protected]>
2025-03-11 04:11 ` Re: Commit fest 2025-03 vignesh C <[email protected]>
2025-03-17 03:56 ` Re: Commit fest 2025-03 vignesh C <[email protected]>
2025-03-24 04:37 ` Re: Commit fest 2025-03 vignesh C <[email protected]>
2025-03-31 03:04 ` Re: Commit fest 2025-03 vignesh C <[email protected]>
2025-04-07 15:07 ` Re: Commit fest 2025-03 vignesh C <[email protected]>
2025-04-09 01:03 ` Re: Commit fest 2025-03 vignesh C <[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