public inbox for [email protected]
help / color / mirror / Atom feed[PATCH v5 3/3] Move code to apply one WAL record to a subroutine.
14+ messages / 4 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; 14+ 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] 14+ messages in thread
* [PATCH 2/4] Adjust tuplesort API to have bitwise flags instead of bool
@ 2022-04-01 07:04 David Rowley <[email protected]>
0 siblings, 0 replies; 14+ messages in thread
From: David Rowley @ 2022-04-01 07:04 UTC (permalink / raw)
For now we only had a single bool option for randomAccess, however an
upcoming patch requires adding another option, so instead of breaking the
API for that, then breaking it again one day if we add more options, let's
just break it once. Any options we add in the future will just make use
of an unused bit in the flags.
Author: David Rowley
Discussion: https://postgr.es/m/CAApHDvoH4ASzsAOyHcxkuY01Qf%2B%2B8JJ0paw%2B03dk%2BW25tQEcNQ%40mail.gmail.com
---
src/backend/access/gist/gistbuild.c | 2 +-
src/backend/access/hash/hashsort.c | 2 +-
src/backend/access/heap/heapam_handler.c | 2 +-
src/backend/access/nbtree/nbtsort.c | 6 +-
src/backend/catalog/index.c | 2 +-
src/backend/executor/nodeAgg.c | 6 +-
src/backend/executor/nodeIncrementalSort.c | 4 +-
src/backend/executor/nodeSort.c | 8 +-
src/backend/utils/adt/orderedsetaggs.c | 10 +-
src/backend/utils/sort/tuplesort.c | 101 +++++++++++----------
src/include/utils/tuplesort.h | 19 ++--
11 files changed, 90 insertions(+), 72 deletions(-)
diff --git a/src/backend/access/gist/gistbuild.c b/src/backend/access/gist/gistbuild.c
index e081e6571a4..f5a5caff8ec 100644
--- a/src/backend/access/gist/gistbuild.c
+++ b/src/backend/access/gist/gistbuild.c
@@ -271,7 +271,7 @@ gistbuild(Relation heap, Relation index, IndexInfo *indexInfo)
index,
maintenance_work_mem,
NULL,
- false);
+ TUPLESORT_NONE);
/* Scan the table, adding all tuples to the tuplesort */
reltuples = table_index_build_scan(heap, index, indexInfo, true, true,
diff --git a/src/backend/access/hash/hashsort.c b/src/backend/access/hash/hashsort.c
index 6d8512283a8..aa61e39f26a 100644
--- a/src/backend/access/hash/hashsort.c
+++ b/src/backend/access/hash/hashsort.c
@@ -86,7 +86,7 @@ _h_spoolinit(Relation heap, Relation index, uint32 num_buckets)
hspool->max_buckets,
maintenance_work_mem,
NULL,
- false);
+ TUPLESORT_NONE);
return hspool;
}
diff --git a/src/backend/access/heap/heapam_handler.c b/src/backend/access/heap/heapam_handler.c
index dee264e8596..3a9532cb4f7 100644
--- a/src/backend/access/heap/heapam_handler.c
+++ b/src/backend/access/heap/heapam_handler.c
@@ -726,7 +726,7 @@ heapam_relation_copy_for_cluster(Relation OldHeap, Relation NewHeap,
if (use_sort)
tuplesort = tuplesort_begin_cluster(oldTupDesc, OldIndex,
maintenance_work_mem,
- NULL, false);
+ NULL, TUPLESORT_NONE);
else
tuplesort = NULL;
diff --git a/src/backend/access/nbtree/nbtsort.c b/src/backend/access/nbtree/nbtsort.c
index 8a19de2f66c..15605dac6bb 100644
--- a/src/backend/access/nbtree/nbtsort.c
+++ b/src/backend/access/nbtree/nbtsort.c
@@ -436,7 +436,7 @@ _bt_spools_heapscan(Relation heap, Relation index, BTBuildState *buildstate,
tuplesort_begin_index_btree(heap, index, buildstate->isunique,
buildstate->nulls_not_distinct,
maintenance_work_mem, coordinate,
- false);
+ TUPLESORT_NONE);
/*
* If building a unique index, put dead tuples in a second spool to keep
@@ -475,7 +475,7 @@ _bt_spools_heapscan(Relation heap, Relation index, BTBuildState *buildstate,
*/
buildstate->spool2->sortstate =
tuplesort_begin_index_btree(heap, index, false, false, work_mem,
- coordinate2, false);
+ coordinate2, TUPLESORT_NONE);
}
/* Fill spool using either serial or parallel heap scan */
@@ -1939,7 +1939,7 @@ _bt_parallel_scan_and_sort(BTSpool *btspool, BTSpool *btspool2,
btspool->isunique,
btspool->nulls_not_distinct,
sortmem, coordinate,
- false);
+ TUPLESORT_NONE);
/*
* Just as with serial case, there may be a second spool. If so, a
diff --git a/src/backend/catalog/index.c b/src/backend/catalog/index.c
index dd715ca0609..55800c94786 100644
--- a/src/backend/catalog/index.c
+++ b/src/backend/catalog/index.c
@@ -3364,7 +3364,7 @@ validate_index(Oid heapId, Oid indexId, Snapshot snapshot)
state.tuplesort = tuplesort_begin_datum(INT8OID, Int8LessOperator,
InvalidOid, false,
maintenance_work_mem,
- NULL, false);
+ NULL, TUPLESORT_NONE);
state.htups = state.itups = state.tups_inserted = 0;
/* ambulkdelete updates progress metrics */
diff --git a/src/backend/executor/nodeAgg.c b/src/backend/executor/nodeAgg.c
index 08cf569d8fa..23030a32a59 100644
--- a/src/backend/executor/nodeAgg.c
+++ b/src/backend/executor/nodeAgg.c
@@ -530,7 +530,7 @@ initialize_phase(AggState *aggstate, int newphase)
sortnode->collations,
sortnode->nullsFirst,
work_mem,
- NULL, false);
+ NULL, TUPLESORT_NONE);
}
aggstate->current_phase = newphase;
@@ -607,7 +607,7 @@ initialize_aggregate(AggState *aggstate, AggStatePerTrans pertrans,
pertrans->sortOperators[0],
pertrans->sortCollations[0],
pertrans->sortNullsFirst[0],
- work_mem, NULL, false);
+ work_mem, NULL, TUPLESORT_NONE);
}
else
pertrans->sortstates[aggstate->current_set] =
@@ -617,7 +617,7 @@ initialize_aggregate(AggState *aggstate, AggStatePerTrans pertrans,
pertrans->sortOperators,
pertrans->sortCollations,
pertrans->sortNullsFirst,
- work_mem, NULL, false);
+ work_mem, NULL, TUPLESORT_NONE);
}
/*
diff --git a/src/backend/executor/nodeIncrementalSort.c b/src/backend/executor/nodeIncrementalSort.c
index d6fb56dec73..4f50bc845da 100644
--- a/src/backend/executor/nodeIncrementalSort.c
+++ b/src/backend/executor/nodeIncrementalSort.c
@@ -315,7 +315,7 @@ switchToPresortedPrefixMode(PlanState *pstate)
&(plannode->sort.nullsFirst[nPresortedCols]),
work_mem,
NULL,
- false);
+ TUPLESORT_NONE);
node->prefixsort_state = prefixsort_state;
}
else
@@ -616,7 +616,7 @@ ExecIncrementalSort(PlanState *pstate)
plannode->sort.nullsFirst,
work_mem,
NULL,
- false);
+ TUPLESORT_NONE);
node->fullsort_state = fullsort_state;
}
else
diff --git a/src/backend/executor/nodeSort.c b/src/backend/executor/nodeSort.c
index 9481a622bf5..a113d737955 100644
--- a/src/backend/executor/nodeSort.c
+++ b/src/backend/executor/nodeSort.c
@@ -77,6 +77,7 @@ ExecSort(PlanState *pstate)
Sort *plannode = (Sort *) node->ss.ps.plan;
PlanState *outerNode;
TupleDesc tupDesc;
+ int tuplesortopts = TUPLESORT_NONE;
SO1_printf("ExecSort: %s\n",
"sorting subplan");
@@ -96,6 +97,9 @@ ExecSort(PlanState *pstate)
outerNode = outerPlanState(node);
tupDesc = ExecGetResultType(outerNode);
+ if (node->randomAccess)
+ tuplesortopts |= TUPLESORT_RANDOMACCESS;
+
if (node->datumSort)
tuplesortstate = tuplesort_begin_datum(TupleDescAttr(tupDesc, 0)->atttypid,
plannode->sortOperators[0],
@@ -103,7 +107,7 @@ ExecSort(PlanState *pstate)
plannode->nullsFirst[0],
work_mem,
NULL,
- node->randomAccess);
+ tuplesortopts);
else
tuplesortstate = tuplesort_begin_heap(tupDesc,
plannode->numCols,
@@ -113,7 +117,7 @@ ExecSort(PlanState *pstate)
plannode->nullsFirst,
work_mem,
NULL,
- node->randomAccess);
+ tuplesortopts);
if (node->bounded)
tuplesort_set_bound(tuplesortstate, node->bound);
node->tuplesortstate = (void *) tuplesortstate;
diff --git a/src/backend/utils/adt/orderedsetaggs.c b/src/backend/utils/adt/orderedsetaggs.c
index 96dae6ec4a8..6d4f6b7dca2 100644
--- a/src/backend/utils/adt/orderedsetaggs.c
+++ b/src/backend/utils/adt/orderedsetaggs.c
@@ -118,6 +118,7 @@ ordered_set_startup(FunctionCallInfo fcinfo, bool use_tuples)
OSAPerQueryState *qstate;
MemoryContext gcontext;
MemoryContext oldcontext;
+ int tuplesortopt;
/*
* Check we're called as aggregate (and not a window function), and get
@@ -283,6 +284,11 @@ ordered_set_startup(FunctionCallInfo fcinfo, bool use_tuples)
osastate->qstate = qstate;
osastate->gcontext = gcontext;
+ tuplesortopt = TUPLESORT_NONE;
+
+ if (qstate->rescan_needed)
+ tuplesortopt |= TUPLESORT_RANDOMACCESS;
+
/*
* Initialize tuplesort object.
*/
@@ -295,7 +301,7 @@ ordered_set_startup(FunctionCallInfo fcinfo, bool use_tuples)
qstate->sortNullsFirsts,
work_mem,
NULL,
- qstate->rescan_needed);
+ tuplesortopt);
else
osastate->sortstate = tuplesort_begin_datum(qstate->sortColType,
qstate->sortOperator,
@@ -303,7 +309,7 @@ ordered_set_startup(FunctionCallInfo fcinfo, bool use_tuples)
qstate->sortNullsFirst,
work_mem,
NULL,
- qstate->rescan_needed);
+ tuplesortopt);
osastate->number_of_rows = 0;
osastate->sort_done = false;
diff --git a/src/backend/utils/sort/tuplesort.c b/src/backend/utils/sort/tuplesort.c
index 086e948fca6..5cc1328febf 100644
--- a/src/backend/utils/sort/tuplesort.c
+++ b/src/backend/utils/sort/tuplesort.c
@@ -246,7 +246,7 @@ struct Tuplesortstate
{
TupSortStatus status; /* enumerated value as shown above */
int nKeys; /* number of columns in sort key */
- bool randomAccess; /* did caller request random access? */
+ int sortopt; /* Bitmask of flags used to setup sort */
bool bounded; /* did caller specify a maximum number of
* tuples to return? */
bool boundUsed; /* true if we made use of a bounded heap */
@@ -558,12 +558,12 @@ struct Sharedsort
* may or may not match the in-memory representation of the tuple ---
* any conversion needed is the job of the writetup and readtup routines.
*
- * If state->randomAccess is true, then the stored representation of the
- * tuple must be followed by another "unsigned int" that is a copy of the
- * length --- so the total tape space used is actually sizeof(unsigned int)
- * more than the stored length value. This allows read-backwards. When
- * randomAccess is not true, the write/read routines may omit the extra
- * length word.
+ * If state->sortopt contains TUPLESORT_RANDOMACCESS, then the stored
+ * representation of the tuple must be followed by another "unsigned int" that
+ * is a copy of the length --- so the total tape space used is actually
+ * sizeof(unsigned int) more than the stored length value. This allows
+ * read-backwards. When the random access flag was not specified, the
+ * write/read routines may omit the extra length word.
*
* writetup is expected to write both length words as well as the tuple
* data. When readtup is called, the tape is positioned just after the
@@ -608,7 +608,7 @@ struct Sharedsort
static Tuplesortstate *tuplesort_begin_common(int workMem,
SortCoordinate coordinate,
- bool randomAccess);
+ int sortopt);
static void tuplesort_begin_batch(Tuplesortstate *state);
static void puttuple_common(Tuplesortstate *state, SortTuple *tuple);
static bool consider_abort_common(Tuplesortstate *state);
@@ -713,21 +713,20 @@ static void tuplesort_updatemax(Tuplesortstate *state);
* Each variant of tuplesort_begin has a workMem parameter specifying the
* maximum number of kilobytes of RAM to use before spilling data to disk.
* (The normal value of this parameter is work_mem, but some callers use
- * other values.) Each variant also has a randomAccess parameter specifying
- * whether the caller needs non-sequential access to the sort result.
+ * other values.) Each variant also has a sortopt which is a bitmask of
+ * sort options. See TUPLESORT_* definitions in tuplesort.h
*/
static Tuplesortstate *
-tuplesort_begin_common(int workMem, SortCoordinate coordinate,
- bool randomAccess)
+tuplesort_begin_common(int workMem, SortCoordinate coordinate, int sortopt)
{
Tuplesortstate *state;
MemoryContext maincontext;
MemoryContext sortcontext;
MemoryContext oldcontext;
- /* See leader_takeover_tapes() remarks on randomAccess support */
- if (coordinate && randomAccess)
+ /* See leader_takeover_tapes() remarks on random access support */
+ if (coordinate && (sortopt & TUPLESORT_RANDOMACCESS))
elog(ERROR, "random access disallowed under parallel sort");
/*
@@ -764,7 +763,7 @@ tuplesort_begin_common(int workMem, SortCoordinate coordinate,
pg_rusage_init(&state->ru_start);
#endif
- state->randomAccess = randomAccess;
+ state->sortopt = sortopt;
state->tuples = true;
/*
@@ -898,10 +897,10 @@ tuplesort_begin_heap(TupleDesc tupDesc,
int nkeys, AttrNumber *attNums,
Oid *sortOperators, Oid *sortCollations,
bool *nullsFirstFlags,
- int workMem, SortCoordinate coordinate, bool randomAccess)
+ int workMem, SortCoordinate coordinate, int sortopt)
{
Tuplesortstate *state = tuplesort_begin_common(workMem, coordinate,
- randomAccess);
+ sortopt);
MemoryContext oldcontext;
int i;
@@ -913,7 +912,7 @@ tuplesort_begin_heap(TupleDesc tupDesc,
if (trace_sort)
elog(LOG,
"begin tuple sort: nkeys = %d, workMem = %d, randomAccess = %c",
- nkeys, workMem, randomAccess ? 't' : 'f');
+ nkeys, workMem, sortopt & TUPLESORT_RANDOMACCESS ? 't' : 'f');
#endif
state->nKeys = nkeys;
@@ -922,7 +921,7 @@ tuplesort_begin_heap(TupleDesc tupDesc,
false, /* no unique check */
nkeys,
workMem,
- randomAccess,
+ sortopt & TUPLESORT_RANDOMACCESS,
PARALLEL_SORT(state));
state->comparetup = comparetup_heap;
@@ -971,10 +970,10 @@ Tuplesortstate *
tuplesort_begin_cluster(TupleDesc tupDesc,
Relation indexRel,
int workMem,
- SortCoordinate coordinate, bool randomAccess)
+ SortCoordinate coordinate, int sortopt)
{
Tuplesortstate *state = tuplesort_begin_common(workMem, coordinate,
- randomAccess);
+ sortopt);
BTScanInsert indexScanKey;
MemoryContext oldcontext;
int i;
@@ -988,7 +987,7 @@ tuplesort_begin_cluster(TupleDesc tupDesc,
elog(LOG,
"begin tuple sort: nkeys = %d, workMem = %d, randomAccess = %c",
RelationGetNumberOfAttributes(indexRel),
- workMem, randomAccess ? 't' : 'f');
+ workMem, sortopt & TUPLESORT_RANDOMACCESS ? 't' : 'f');
#endif
state->nKeys = IndexRelationGetNumberOfKeyAttributes(indexRel);
@@ -997,7 +996,7 @@ tuplesort_begin_cluster(TupleDesc tupDesc,
false, /* no unique check */
state->nKeys,
workMem,
- randomAccess,
+ sortopt & TUPLESORT_RANDOMACCESS,
PARALLEL_SORT(state));
state->comparetup = comparetup_cluster;
@@ -1069,10 +1068,10 @@ tuplesort_begin_index_btree(Relation heapRel,
bool uniqueNullsNotDistinct,
int workMem,
SortCoordinate coordinate,
- bool randomAccess)
+ int sortopt)
{
Tuplesortstate *state = tuplesort_begin_common(workMem, coordinate,
- randomAccess);
+ sortopt);
BTScanInsert indexScanKey;
MemoryContext oldcontext;
int i;
@@ -1084,7 +1083,7 @@ tuplesort_begin_index_btree(Relation heapRel,
elog(LOG,
"begin index sort: unique = %c, workMem = %d, randomAccess = %c",
enforceUnique ? 't' : 'f',
- workMem, randomAccess ? 't' : 'f');
+ workMem, sortopt & TUPLESORT_RANDOMACCESS ? 't' : 'f');
#endif
state->nKeys = IndexRelationGetNumberOfKeyAttributes(indexRel);
@@ -1093,7 +1092,7 @@ tuplesort_begin_index_btree(Relation heapRel,
enforceUnique,
state->nKeys,
workMem,
- randomAccess,
+ sortopt & TUPLESORT_RANDOMACCESS,
PARALLEL_SORT(state));
state->comparetup = comparetup_index_btree;
@@ -1150,10 +1149,10 @@ tuplesort_begin_index_hash(Relation heapRel,
uint32 max_buckets,
int workMem,
SortCoordinate coordinate,
- bool randomAccess)
+ int sortopt)
{
Tuplesortstate *state = tuplesort_begin_common(workMem, coordinate,
- randomAccess);
+ sortopt);
MemoryContext oldcontext;
oldcontext = MemoryContextSwitchTo(state->maincontext);
@@ -1166,7 +1165,8 @@ tuplesort_begin_index_hash(Relation heapRel,
high_mask,
low_mask,
max_buckets,
- workMem, randomAccess ? 't' : 'f');
+ workMem,
+ sortopt & TUPLESORT_RANDOMACCESS ? 't' : 'f');
#endif
state->nKeys = 1; /* Only one sort column, the hash code */
@@ -1193,10 +1193,10 @@ tuplesort_begin_index_gist(Relation heapRel,
Relation indexRel,
int workMem,
SortCoordinate coordinate,
- bool randomAccess)
+ int sortopt)
{
Tuplesortstate *state = tuplesort_begin_common(workMem, coordinate,
- randomAccess);
+ sortopt);
MemoryContext oldcontext;
int i;
@@ -1206,7 +1206,7 @@ tuplesort_begin_index_gist(Relation heapRel,
if (trace_sort)
elog(LOG,
"begin index sort: workMem = %d, randomAccess = %c",
- workMem, randomAccess ? 't' : 'f');
+ workMem, sortopt & TUPLESORT_RANDOMACCESS ? 't' : 'f');
#endif
state->nKeys = IndexRelationGetNumberOfKeyAttributes(indexRel);
@@ -1248,10 +1248,10 @@ tuplesort_begin_index_gist(Relation heapRel,
Tuplesortstate *
tuplesort_begin_datum(Oid datumType, Oid sortOperator, Oid sortCollation,
bool nullsFirstFlag, int workMem,
- SortCoordinate coordinate, bool randomAccess)
+ SortCoordinate coordinate, int sortopt)
{
Tuplesortstate *state = tuplesort_begin_common(workMem, coordinate,
- randomAccess);
+ sortopt);
MemoryContext oldcontext;
int16 typlen;
bool typbyval;
@@ -1262,7 +1262,7 @@ tuplesort_begin_datum(Oid datumType, Oid sortOperator, Oid sortCollation,
if (trace_sort)
elog(LOG,
"begin datum sort: workMem = %d, randomAccess = %c",
- workMem, randomAccess ? 't' : 'f');
+ workMem, sortopt & TUPLESORT_RANDOMACCESS ? 't' : 'f');
#endif
state->nKeys = 1; /* always a one-column sort */
@@ -2165,7 +2165,7 @@ tuplesort_gettuple_common(Tuplesortstate *state, bool forward,
switch (state->status)
{
case TSS_SORTEDINMEM:
- Assert(forward || state->randomAccess);
+ Assert(forward || state->sortopt & TUPLESORT_RANDOMACCESS);
Assert(!state->slabAllocatorUsed);
if (forward)
{
@@ -2209,7 +2209,7 @@ tuplesort_gettuple_common(Tuplesortstate *state, bool forward,
break;
case TSS_SORTEDONTAPE:
- Assert(forward || state->randomAccess);
+ Assert(forward || state->sortopt & TUPLESORT_RANDOMACCESS);
Assert(state->slabAllocatorUsed);
/*
@@ -2984,7 +2984,8 @@ mergeruns(Tuplesortstate *state)
* sorted tape, we can stop at this point and do the final merge
* on-the-fly.
*/
- if (!state->randomAccess && state->nInputRuns <= state->nInputTapes
+ if ((state->sortopt & TUPLESORT_RANDOMACCESS) == 0
+ && state->nInputRuns <= state->nInputTapes
&& !WORKER(state))
{
/* Tell logtape.c we won't be writing anymore */
@@ -3230,7 +3231,7 @@ tuplesort_rescan(Tuplesortstate *state)
{
MemoryContext oldcontext = MemoryContextSwitchTo(state->sortcontext);
- Assert(state->randomAccess);
+ Assert(state->sortopt & TUPLESORT_RANDOMACCESS);
switch (state->status)
{
@@ -3263,7 +3264,7 @@ tuplesort_markpos(Tuplesortstate *state)
{
MemoryContext oldcontext = MemoryContextSwitchTo(state->sortcontext);
- Assert(state->randomAccess);
+ Assert(state->sortopt & TUPLESORT_RANDOMACCESS);
switch (state->status)
{
@@ -3294,7 +3295,7 @@ tuplesort_restorepos(Tuplesortstate *state)
{
MemoryContext oldcontext = MemoryContextSwitchTo(state->sortcontext);
- Assert(state->randomAccess);
+ Assert(state->sortopt & TUPLESORT_RANDOMACCESS);
switch (state->status)
{
@@ -3853,7 +3854,7 @@ writetup_heap(Tuplesortstate *state, LogicalTape *tape, SortTuple *stup)
LogicalTapeWrite(tape, (void *) &tuplen, sizeof(tuplen));
LogicalTapeWrite(tape, (void *) tupbody, tupbodylen);
- if (state->randomAccess) /* need trailing length word? */
+ if (state->sortopt & TUPLESORT_RANDOMACCESS) /* need trailing length word? */
LogicalTapeWrite(tape, (void *) &tuplen, sizeof(tuplen));
if (!state->slabAllocatorUsed)
@@ -3876,7 +3877,7 @@ readtup_heap(Tuplesortstate *state, SortTuple *stup,
/* read in the tuple proper */
tuple->t_len = tuplen;
LogicalTapeReadExact(tape, tupbody, tupbodylen);
- if (state->randomAccess) /* need trailing length word? */
+ if (state->sortopt & TUPLESORT_RANDOMACCESS) /* need trailing length word? */
LogicalTapeReadExact(tape, &tuplen, sizeof(tuplen));
stup->tuple = (void *) tuple;
/* set up first-column key value */
@@ -4087,7 +4088,7 @@ writetup_cluster(Tuplesortstate *state, LogicalTape *tape, SortTuple *stup)
LogicalTapeWrite(tape, &tuplen, sizeof(tuplen));
LogicalTapeWrite(tape, &tuple->t_self, sizeof(ItemPointerData));
LogicalTapeWrite(tape, tuple->t_data, tuple->t_len);
- if (state->randomAccess) /* need trailing length word? */
+ if (state->sortopt & TUPLESORT_RANDOMACCESS) /* need trailing length word? */
LogicalTapeWrite(tape, &tuplen, sizeof(tuplen));
if (!state->slabAllocatorUsed)
@@ -4113,7 +4114,7 @@ readtup_cluster(Tuplesortstate *state, SortTuple *stup,
tuple->t_tableOid = InvalidOid;
/* Read in the tuple body */
LogicalTapeReadExact(tape, tuple->t_data, tuple->t_len);
- if (state->randomAccess) /* need trailing length word? */
+ if (state->sortopt & TUPLESORT_RANDOMACCESS) /* need trailing length word? */
LogicalTapeReadExact(tape, &tuplen, sizeof(tuplen));
stup->tuple = (void *) tuple;
/* set up first-column key value, if it's a simple column */
@@ -4337,7 +4338,7 @@ writetup_index(Tuplesortstate *state, LogicalTape *tape, SortTuple *stup)
tuplen = IndexTupleSize(tuple) + sizeof(tuplen);
LogicalTapeWrite(tape, (void *) &tuplen, sizeof(tuplen));
LogicalTapeWrite(tape, (void *) tuple, IndexTupleSize(tuple));
- if (state->randomAccess) /* need trailing length word? */
+ if (state->sortopt & TUPLESORT_RANDOMACCESS) /* need trailing length word? */
LogicalTapeWrite(tape, (void *) &tuplen, sizeof(tuplen));
if (!state->slabAllocatorUsed)
@@ -4355,7 +4356,7 @@ readtup_index(Tuplesortstate *state, SortTuple *stup,
IndexTuple tuple = (IndexTuple) readtup_alloc(state, tuplen);
LogicalTapeReadExact(tape, tuple, tuplen);
- if (state->randomAccess) /* need trailing length word? */
+ if (state->sortopt & TUPLESORT_RANDOMACCESS) /* need trailing length word? */
LogicalTapeReadExact(tape, &tuplen, sizeof(tuplen));
stup->tuple = (void *) tuple;
/* set up first-column key value */
@@ -4425,7 +4426,7 @@ writetup_datum(Tuplesortstate *state, LogicalTape *tape, SortTuple *stup)
LogicalTapeWrite(tape, (void *) &writtenlen, sizeof(writtenlen));
LogicalTapeWrite(tape, waddr, tuplen);
- if (state->randomAccess) /* need trailing length word? */
+ if (state->sortopt & TUPLESORT_RANDOMACCESS) /* need trailing length word? */
LogicalTapeWrite(tape, (void *) &writtenlen, sizeof(writtenlen));
if (!state->slabAllocatorUsed && stup->tuple)
@@ -4465,7 +4466,7 @@ readtup_datum(Tuplesortstate *state, SortTuple *stup,
stup->tuple = raddr;
}
- if (state->randomAccess) /* need trailing length word? */
+ if (state->sortopt & TUPLESORT_RANDOMACCESS) /* need trailing length word? */
LogicalTapeReadExact(tape, &tuplen, sizeof(tuplen));
}
diff --git a/src/include/utils/tuplesort.h b/src/include/utils/tuplesort.h
index da5ba591989..345f4ce8024 100644
--- a/src/include/utils/tuplesort.h
+++ b/src/include/utils/tuplesort.h
@@ -86,6 +86,12 @@ typedef enum
SORT_SPACE_TYPE_MEMORY
} TuplesortSpaceType;
+/* Bitwise option flags for tuple sorts */
+#define TUPLESORT_NONE 0
+
+/* specifies whether non-sequential access to the sort result is required */
+#define TUPLESORT_RANDOMACCESS (1 << 0)
+
typedef struct TuplesortInstrumentation
{
TuplesortMethod sortMethod; /* sort algorithm used */
@@ -201,32 +207,33 @@ extern Tuplesortstate *tuplesort_begin_heap(TupleDesc tupDesc,
Oid *sortOperators, Oid *sortCollations,
bool *nullsFirstFlags,
int workMem, SortCoordinate coordinate,
- bool randomAccess);
+ int sortopt);
extern Tuplesortstate *tuplesort_begin_cluster(TupleDesc tupDesc,
Relation indexRel, int workMem,
- SortCoordinate coordinate, bool randomAccess);
+ SortCoordinate coordinate,
+ int sortopt);
extern Tuplesortstate *tuplesort_begin_index_btree(Relation heapRel,
Relation indexRel,
bool enforceUnique,
bool uniqueNullsNotDistinct,
int workMem, SortCoordinate coordinate,
- bool randomAccess);
+ int sortopt);
extern Tuplesortstate *tuplesort_begin_index_hash(Relation heapRel,
Relation indexRel,
uint32 high_mask,
uint32 low_mask,
uint32 max_buckets,
int workMem, SortCoordinate coordinate,
- bool randomAccess);
+ int sortopt);
extern Tuplesortstate *tuplesort_begin_index_gist(Relation heapRel,
Relation indexRel,
int workMem, SortCoordinate coordinate,
- bool randomAccess);
+ int sortopt);
extern Tuplesortstate *tuplesort_begin_datum(Oid datumType,
Oid sortOperator, Oid sortCollation,
bool nullsFirstFlag,
int workMem, SortCoordinate coordinate,
- bool randomAccess);
+ int sortopt);
extern void tuplesort_set_bound(Tuplesortstate *state, int64 bound);
extern bool tuplesort_used_bound(Tuplesortstate *state);
--
2.17.1
--RHnfto7yGd+QdmRl
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment; filename="0003-f.patch"
^ permalink raw reply [nested|flat] 14+ messages in thread
* Commit fest 2025-03
@ 2025-02-25 16:19 vignesh C <[email protected]>
2025-03-03 09:32 ` Re: Commit fest 2025-03 vignesh C <[email protected]>
0 siblings, 1 reply; 14+ 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] 14+ messages in thread
* Re: Commit fest 2025-03
2025-02-25 16:19 Commit fest 2025-03 vignesh C <[email protected]>
@ 2025-03-03 09:32 ` vignesh C <[email protected]>
2025-03-05 09:22 ` Re: Commit fest 2025-03 vignesh C <[email protected]>
2025-03-11 04:11 ` Re: Commit fest 2025-03 vignesh C <[email protected]>
0 siblings, 2 replies; 14+ 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] 14+ messages in thread
* Re: Commit fest 2025-03
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 ` vignesh C <[email protected]>
2025-03-05 11:20 ` Re: Commit fest 2025-03 Jim Jones <[email protected]>
1 sibling, 1 reply; 14+ 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] 14+ messages in thread
* Re: Commit fest 2025-03
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 ` 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]>
0 siblings, 2 replies; 14+ 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] 14+ messages in thread
* Re: Commit fest 2025-03
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 ` vignesh C <[email protected]>
1 sibling, 0 replies; 14+ 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] 14+ messages in thread
* Re: Commit fest 2025-03
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-09 12:10 ` vignesh C <[email protected]>
1 sibling, 0 replies; 14+ 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] 14+ messages in thread
* Re: Commit fest 2025-03
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-11 04:11 ` vignesh C <[email protected]>
2025-03-17 03:56 ` Re: Commit fest 2025-03 vignesh C <[email protected]>
1 sibling, 1 reply; 14+ 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] 14+ messages in thread
* Re: Commit fest 2025-03
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-11 04:11 ` Re: Commit fest 2025-03 vignesh C <[email protected]>
@ 2025-03-17 03:56 ` vignesh C <[email protected]>
2025-03-24 04:37 ` Re: Commit fest 2025-03 vignesh C <[email protected]>
0 siblings, 1 reply; 14+ 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] 14+ messages in thread
* Re: Commit fest 2025-03
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-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 ` vignesh C <[email protected]>
2025-03-31 03:04 ` Re: Commit fest 2025-03 vignesh C <[email protected]>
0 siblings, 1 reply; 14+ 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] 14+ messages in thread
* Re: Commit fest 2025-03
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-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 ` vignesh C <[email protected]>
2025-04-07 15:07 ` Re: Commit fest 2025-03 vignesh C <[email protected]>
0 siblings, 1 reply; 14+ 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] 14+ messages in thread
* Re: Commit fest 2025-03
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-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 ` vignesh C <[email protected]>
2025-04-09 01:03 ` Re: Commit fest 2025-03 vignesh C <[email protected]>
0 siblings, 1 reply; 14+ 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] 14+ messages in thread
* Re: Commit fest 2025-03
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-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 ` vignesh C <[email protected]>
0 siblings, 0 replies; 14+ 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] 14+ messages in thread
end of thread, other threads:[~2025-04-09 01:03 UTC | newest]
Thread overview: 14+ 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]>
2022-04-01 07:04 [PATCH 2/4] Adjust tuplesort API to have bitwise flags instead of bool David Rowley <[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