public inbox for [email protected]
help / color / mirror / Atom feed[PATCH v18 15/18] tableam: bitmap heap scan.
33+ messages / 14 participants
[nested] [flat]
* [PATCH v18 15/18] tableam: bitmap heap scan.
@ 2019-01-20 08:11 Andres Freund <[email protected]>
0 siblings, 0 replies; 33+ messages in thread
From: Andres Freund @ 2019-01-20 08:11 UTC (permalink / raw)
Author:
Reviewed-By:
Discussion: https://postgr.es/m/
Backpatch:
---
src/backend/access/heap/heapam_handler.c | 147 ++++++++++++
src/backend/executor/nodeBitmapHeapscan.c | 266 +++++-----------------
src/backend/optimizer/util/plancat.c | 3 +-
src/include/access/tableam.h | 17 ++
4 files changed, 223 insertions(+), 210 deletions(-)
diff --git a/src/backend/access/heap/heapam_handler.c b/src/backend/access/heap/heapam_handler.c
index f71b9b2a062..b183b22ca16 100644
--- a/src/backend/access/heap/heapam_handler.c
+++ b/src/backend/access/heap/heapam_handler.c
@@ -1806,6 +1806,151 @@ heapam_index_validate_scan(Relation heapRelation,
indexInfo->ii_PredicateState = NULL;
}
+static bool
+heapam_scan_bitmap_pagescan(TableScanDesc sscan,
+ TBMIterateResult *tbmres)
+{
+ HeapScanDesc scan = (HeapScanDesc) sscan;
+ BlockNumber page = tbmres->blockno;
+ Buffer buffer;
+ Snapshot snapshot;
+ int ntup;
+
+ scan->rs_cindex = 0;
+ scan->rs_ntuples = 0;
+
+ /*
+ * Ignore any claimed entries past what we think is the end of the
+ * relation. (This is probably not necessary given that we got at least
+ * AccessShareLock on the table before performing any of the indexscans,
+ * but let's be safe.)
+ */
+ if (page >= scan->rs_nblocks)
+ return false;
+
+ scan->rs_cbuf = ReleaseAndReadBuffer(scan->rs_cbuf,
+ scan->rs_base.rs_rd,
+ page);
+ scan->rs_cblock = page;
+ buffer = scan->rs_cbuf;
+ snapshot = scan->rs_base.rs_snapshot;
+
+ ntup = 0;
+
+ /*
+ * Prune and repair fragmentation for the whole page, if possible.
+ */
+ heap_page_prune_opt(scan->rs_base.rs_rd, buffer);
+
+ /*
+ * We must hold share lock on the buffer content while examining tuple
+ * visibility. Afterwards, however, the tuples we have found to be
+ * visible are guaranteed good as long as we hold the buffer pin.
+ */
+ LockBuffer(buffer, BUFFER_LOCK_SHARE);
+
+ /*
+ * We need two separate strategies for lossy and non-lossy cases.
+ */
+ if (tbmres->ntuples >= 0)
+ {
+ /*
+ * Bitmap is non-lossy, so we just look through the offsets listed in
+ * tbmres; but we have to follow any HOT chain starting at each such
+ * offset.
+ */
+ int curslot;
+
+ for (curslot = 0; curslot < tbmres->ntuples; curslot++)
+ {
+ OffsetNumber offnum = tbmres->offsets[curslot];
+ ItemPointerData tid;
+ HeapTupleData heapTuple;
+
+ ItemPointerSet(&tid, page, offnum);
+ if (heap_hot_search_buffer(&tid, sscan->rs_rd, buffer, snapshot,
+ &heapTuple, NULL, true))
+ scan->rs_vistuples[ntup++] = ItemPointerGetOffsetNumber(&tid);
+ }
+ }
+ else
+ {
+ /*
+ * Bitmap is lossy, so we must examine each item pointer on the page.
+ * But we can ignore HOT chains, since we'll check each tuple anyway.
+ */
+ Page dp = (Page) BufferGetPage(buffer);
+ OffsetNumber maxoff = PageGetMaxOffsetNumber(dp);
+ OffsetNumber offnum;
+
+ for (offnum = FirstOffsetNumber; offnum <= maxoff; offnum = OffsetNumberNext(offnum))
+ {
+ ItemId lp;
+ HeapTupleData loctup;
+ bool valid;
+
+ lp = PageGetItemId(dp, offnum);
+ if (!ItemIdIsNormal(lp))
+ continue;
+ loctup.t_data = (HeapTupleHeader) PageGetItem((Page) dp, lp);
+ loctup.t_len = ItemIdGetLength(lp);
+ loctup.t_tableOid = scan->rs_base.rs_rd->rd_id;
+ ItemPointerSet(&loctup.t_self, page, offnum);
+ valid = HeapTupleSatisfiesVisibility(&loctup, snapshot, buffer);
+ if (valid)
+ {
+ scan->rs_vistuples[ntup++] = offnum;
+ PredicateLockTuple(scan->rs_base.rs_rd, &loctup, snapshot);
+ }
+ CheckForSerializableConflictOut(valid, scan->rs_base.rs_rd, &loctup,
+ buffer, snapshot);
+ }
+ }
+
+ LockBuffer(buffer, BUFFER_LOCK_UNLOCK);
+
+ Assert(ntup <= MaxHeapTuplesPerPage);
+ scan->rs_ntuples = ntup;
+
+ return ntup > 0;
+}
+
+static bool
+heapam_scan_bitmap_pagescan_next(TableScanDesc sscan, TupleTableSlot *slot)
+{
+ HeapScanDesc scan = (HeapScanDesc) sscan;
+ OffsetNumber targoffset;
+ Page dp;
+ ItemId lp;
+
+ if (scan->rs_cindex < 0 || scan->rs_cindex >= scan->rs_ntuples)
+ return false;
+
+ targoffset = scan->rs_vistuples[scan->rs_cindex];
+ dp = (Page) BufferGetPage(scan->rs_cbuf);
+ lp = PageGetItemId(dp, targoffset);
+ Assert(ItemIdIsNormal(lp));
+
+ scan->rs_ctup.t_data = (HeapTupleHeader) PageGetItem((Page) dp, lp);
+ scan->rs_ctup.t_len = ItemIdGetLength(lp);
+ scan->rs_ctup.t_tableOid = scan->rs_base.rs_rd->rd_id;
+ ItemPointerSet(&scan->rs_ctup.t_self, scan->rs_cblock, targoffset);
+
+ pgstat_count_heap_fetch(scan->rs_base.rs_rd);
+
+ /*
+ * Set up the result slot to point to this tuple. Note that the slot
+ * acquires a pin on the buffer.
+ */
+ ExecStoreBufferHeapTuple(&scan->rs_ctup,
+ slot,
+ scan->rs_cbuf);
+
+ scan->rs_cindex++;
+
+ return true;
+}
+
/*
* Check visibility of the tuple.
*/
@@ -2208,6 +2353,8 @@ static const TableAmRoutine heapam_methods = {
.relation_estimate_size = heapam_estimate_rel_size,
+ .scan_bitmap_pagescan = heapam_scan_bitmap_pagescan,
+ .scan_bitmap_pagescan_next = heapam_scan_bitmap_pagescan_next,
.scan_sample_next_block = heapam_scan_sample_next_block,
.scan_sample_next_tuple = heapam_scan_sample_next_tuple
};
diff --git a/src/backend/executor/nodeBitmapHeapscan.c b/src/backend/executor/nodeBitmapHeapscan.c
index 3a82857770c..59061c746b1 100644
--- a/src/backend/executor/nodeBitmapHeapscan.c
+++ b/src/backend/executor/nodeBitmapHeapscan.c
@@ -37,7 +37,6 @@
#include <math.h>
-#include "access/heapam.h"
#include "access/relscan.h"
#include "access/tableam.h"
#include "access/transam.h"
@@ -55,7 +54,6 @@
static TupleTableSlot *BitmapHeapNext(BitmapHeapScanState *node);
-static void bitgetpage(HeapScanDesc scan, TBMIterateResult *tbmres);
static inline void BitmapDoneInitializingSharedState(
ParallelBitmapHeapState *pstate);
static inline void BitmapAdjustPrefetchIterator(BitmapHeapScanState *node,
@@ -78,12 +76,10 @@ BitmapHeapNext(BitmapHeapScanState *node)
{
ExprContext *econtext;
TableScanDesc scan;
- HeapScanDesc hscan;
TIDBitmap *tbm;
TBMIterator *tbmiterator = NULL;
TBMSharedIterator *shared_tbmiterator = NULL;
TBMIterateResult *tbmres;
- OffsetNumber targoffset;
TupleTableSlot *slot;
ParallelBitmapHeapState *pstate = node->pstate;
dsa_area *dsa = node->ss.ps.state->es_query_dsa;
@@ -94,7 +90,6 @@ BitmapHeapNext(BitmapHeapScanState *node)
econtext = node->ss.ps.ps_ExprContext;
slot = node->ss.ss_ScanTupleSlot;
scan = node->ss.ss_currentScanDesc;
- hscan = (HeapScanDesc) scan;
tbm = node->tbm;
if (pstate == NULL)
tbmiterator = node->tbmiterator;
@@ -194,16 +189,27 @@ BitmapHeapNext(BitmapHeapScanState *node)
for (;;)
{
- Page dp;
- ItemId lp;
-
CHECK_FOR_INTERRUPTS();
- /*
- * Get next page of results if needed
- */
- if (tbmres == NULL)
+ if (node->return_empty_tuples > 0)
{
+ ExecStoreAllNullTuple(slot);
+ node->return_empty_tuples--;
+ }
+ else if (tbmres)
+ {
+ if (!table_scan_bitmap_pagescan_next(scan, slot))
+ {
+ node->tbmres = tbmres = NULL;
+ continue;
+ }
+ }
+ else
+ {
+ /*
+ * Get next page of results if needed
+ */
+
if (!pstate)
node->tbmres = tbmres = tbm_iterate(tbmiterator);
else
@@ -216,18 +222,6 @@ BitmapHeapNext(BitmapHeapScanState *node)
BitmapAdjustPrefetchIterator(node, tbmres);
- /*
- * Ignore any claimed entries past what we think is the end of the
- * relation. (This is probably not necessary given that we got at
- * least AccessShareLock on the table before performing any of the
- * indexscans, but let's be safe.)
- */
- if (tbmres->blockno >= hscan->rs_nblocks)
- {
- node->tbmres = tbmres = NULL;
- continue;
- }
-
/*
* We can skip fetching the heap page if we don't need any fields
* from the heap, and the bitmap entries don't need rechecking,
@@ -243,16 +237,21 @@ BitmapHeapNext(BitmapHeapScanState *node)
{
/*
* The number of tuples on this page is put into
- * scan->rs_ntuples; note we don't fill scan->rs_vistuples.
+ * node->return_empty_tuples; note we don't fill
+ * scan->rs_vistuples.
*/
- hscan->rs_ntuples = tbmres->ntuples;
+ node->return_empty_tuples = tbmres->ntuples;
}
else
{
/*
* Fetch the current heap page and identify candidate tuples.
*/
- bitgetpage(hscan, tbmres);
+ if (!table_scan_bitmap_pagescan(scan, tbmres))
+ {
+ /* AM doesn't think this block is valid, skip */
+ continue;
+ }
}
if (tbmres->ntuples >= 0)
@@ -260,51 +259,37 @@ BitmapHeapNext(BitmapHeapScanState *node)
else
node->lossy_pages++;
- /*
- * Set rs_cindex to first slot to examine
- */
- hscan->rs_cindex = 0;
-
/* Adjust the prefetch target */
BitmapAdjustPrefetchTarget(node);
- }
- else
- {
+
/*
- * Continuing in previously obtained page; advance rs_cindex
+ * XXX: Note we do not prefetch here.
*/
- hscan->rs_cindex++;
+
+ continue;
+ }
+
#ifdef USE_PREFETCH
- /*
- * Try to prefetch at least a few pages even before we get to the
- * second page if we don't stop reading after the first tuple.
- */
- if (!pstate)
- {
- if (node->prefetch_target < node->prefetch_maximum)
- node->prefetch_target++;
- }
- else if (pstate->prefetch_target < node->prefetch_maximum)
- {
- /* take spinlock while updating shared state */
- SpinLockAcquire(&pstate->mutex);
- if (pstate->prefetch_target < node->prefetch_maximum)
- pstate->prefetch_target++;
- SpinLockRelease(&pstate->mutex);
- }
-#endif /* USE_PREFETCH */
- }
-
/*
- * Out of range? If so, nothing more to look at on this page
+ * Try to prefetch at least a few pages even before we get to the
+ * second page if we don't stop reading after the first tuple.
*/
- if (hscan->rs_cindex < 0 || hscan->rs_cindex >= hscan->rs_ntuples)
+ if (!pstate)
{
- node->tbmres = tbmres = NULL;
- continue;
+ if (node->prefetch_target < node->prefetch_maximum)
+ node->prefetch_target++;
}
+ else if (pstate->prefetch_target < node->prefetch_maximum)
+ {
+ /* take spinlock while updating shared state */
+ SpinLockAcquire(&pstate->mutex);
+ if (pstate->prefetch_target < node->prefetch_maximum)
+ pstate->prefetch_target++;
+ SpinLockRelease(&pstate->mutex);
+ }
+#endif /* USE_PREFETCH */
/*
* We issue prefetch requests *after* fetching the current page to try
@@ -315,52 +300,19 @@ BitmapHeapNext(BitmapHeapScanState *node)
*/
BitmapPrefetch(node, scan);
- if (node->skip_fetch)
+ /*
+ * If we are using lossy info, we have to recheck the qual conditions
+ * at every tuple.
+ */
+ if (tbmres->recheck)
{
- /*
- * If we don't have to fetch the tuple, just return nulls.
- */
- ExecStoreAllNullTuple(slot);
- }
- else
- {
- /*
- * Okay to fetch the tuple.
- */
- targoffset = hscan->rs_vistuples[hscan->rs_cindex];
- dp = (Page) BufferGetPage(hscan->rs_cbuf);
- lp = PageGetItemId(dp, targoffset);
- Assert(ItemIdIsNormal(lp));
-
- hscan->rs_ctup.t_data = (HeapTupleHeader) PageGetItem((Page) dp, lp);
- hscan->rs_ctup.t_len = ItemIdGetLength(lp);
- hscan->rs_ctup.t_tableOid = scan->rs_rd->rd_id;
- ItemPointerSet(&hscan->rs_ctup.t_self, tbmres->blockno, targoffset);
-
- pgstat_count_heap_fetch(scan->rs_rd);
-
- /*
- * Set up the result slot to point to this tuple. Note that the
- * slot acquires a pin on the buffer.
- */
- ExecStoreBufferHeapTuple(&hscan->rs_ctup,
- slot,
- hscan->rs_cbuf);
-
- /*
- * If we are using lossy info, we have to recheck the qual
- * conditions at every tuple.
- */
- if (tbmres->recheck)
+ econtext->ecxt_scantuple = slot;
+ if (!ExecQualAndReset(node->bitmapqualorig, econtext))
{
- econtext->ecxt_scantuple = slot;
- if (!ExecQualAndReset(node->bitmapqualorig, econtext))
- {
- /* Fails recheck, so drop it and loop back for another */
- InstrCountFiltered2(node, 1);
- ExecClearTuple(slot);
- continue;
- }
+ /* Fails recheck, so drop it and loop back for another */
+ InstrCountFiltered2(node, 1);
+ ExecClearTuple(slot);
+ continue;
}
}
@@ -374,110 +326,6 @@ BitmapHeapNext(BitmapHeapScanState *node)
return ExecClearTuple(slot);
}
-/*
- * bitgetpage - subroutine for BitmapHeapNext()
- *
- * This routine reads and pins the specified page of the relation, then
- * builds an array indicating which tuples on the page are both potentially
- * interesting according to the bitmap, and visible according to the snapshot.
- */
-static void
-bitgetpage(HeapScanDesc scan, TBMIterateResult *tbmres)
-{
- BlockNumber page = tbmres->blockno;
- Buffer buffer;
- Snapshot snapshot;
- int ntup;
-
- /*
- * Acquire pin on the target heap page, trading in any pin we held before.
- */
- Assert(page < scan->rs_nblocks);
-
- scan->rs_cbuf = ReleaseAndReadBuffer(scan->rs_cbuf,
- scan->rs_base.rs_rd,
- page);
- buffer = scan->rs_cbuf;
- snapshot = scan->rs_base.rs_snapshot;
-
- ntup = 0;
-
- /*
- * Prune and repair fragmentation for the whole page, if possible.
- */
- heap_page_prune_opt(scan->rs_base.rs_rd, buffer);
-
- /*
- * We must hold share lock on the buffer content while examining tuple
- * visibility. Afterwards, however, the tuples we have found to be
- * visible are guaranteed good as long as we hold the buffer pin.
- */
- LockBuffer(buffer, BUFFER_LOCK_SHARE);
-
- /*
- * We need two separate strategies for lossy and non-lossy cases.
- */
- if (tbmres->ntuples >= 0)
- {
- /*
- * Bitmap is non-lossy, so we just look through the offsets listed in
- * tbmres; but we have to follow any HOT chain starting at each such
- * offset.
- */
- int curslot;
-
- for (curslot = 0; curslot < tbmres->ntuples; curslot++)
- {
- OffsetNumber offnum = tbmres->offsets[curslot];
- ItemPointerData tid;
- HeapTupleData heapTuple;
-
- ItemPointerSet(&tid, page, offnum);
- if (heap_hot_search_buffer(&tid, scan->rs_base.rs_rd, buffer,
- snapshot, &heapTuple, NULL, true))
- scan->rs_vistuples[ntup++] = ItemPointerGetOffsetNumber(&tid);
- }
- }
- else
- {
- /*
- * Bitmap is lossy, so we must examine each item pointer on the page.
- * But we can ignore HOT chains, since we'll check each tuple anyway.
- */
- Page dp = (Page) BufferGetPage(buffer);
- OffsetNumber maxoff = PageGetMaxOffsetNumber(dp);
- OffsetNumber offnum;
-
- for (offnum = FirstOffsetNumber; offnum <= maxoff; offnum = OffsetNumberNext(offnum))
- {
- ItemId lp;
- HeapTupleData loctup;
- bool valid;
-
- lp = PageGetItemId(dp, offnum);
- if (!ItemIdIsNormal(lp))
- continue;
- loctup.t_data = (HeapTupleHeader) PageGetItem((Page) dp, lp);
- loctup.t_len = ItemIdGetLength(lp);
- loctup.t_tableOid = scan->rs_base.rs_rd->rd_id;
- ItemPointerSet(&loctup.t_self, page, offnum);
- valid = HeapTupleSatisfiesVisibility(&loctup, snapshot, buffer);
- if (valid)
- {
- scan->rs_vistuples[ntup++] = offnum;
- PredicateLockTuple(scan->rs_base.rs_rd, &loctup, snapshot);
- }
- CheckForSerializableConflictOut(valid, scan->rs_base.rs_rd,
- &loctup, buffer, snapshot);
- }
- }
-
- LockBuffer(buffer, BUFFER_LOCK_UNLOCK);
-
- Assert(ntup <= MaxHeapTuplesPerPage);
- scan->rs_ntuples = ntup;
-}
-
/*
* BitmapDoneInitializingSharedState - Shared state is initialized
*
diff --git a/src/backend/optimizer/util/plancat.c b/src/backend/optimizer/util/plancat.c
index 5ee829bb24e..8ee8821a3ef 100644
--- a/src/backend/optimizer/util/plancat.c
+++ b/src/backend/optimizer/util/plancat.c
@@ -273,7 +273,8 @@ get_relation_info(PlannerInfo *root, Oid relationObjectId, bool inhparent,
info->amsearchnulls = amroutine->amsearchnulls;
info->amcanparallel = amroutine->amcanparallel;
info->amhasgettuple = (amroutine->amgettuple != NULL);
- info->amhasgetbitmap = (amroutine->amgetbitmap != NULL);
+ info->amhasgetbitmap = amroutine->amgetbitmap != NULL &&
+ relation->rd_tableam->scan_bitmap_pagescan != NULL;
info->amcostestimate = amroutine->amcostestimate;
Assert(info->amcostestimate != NULL);
diff --git a/src/include/access/tableam.h b/src/include/access/tableam.h
index 0c9339c676e..2ed25ec748f 100644
--- a/src/include/access/tableam.h
+++ b/src/include/access/tableam.h
@@ -351,6 +351,10 @@ typedef struct TableAmRoutine
* ------------------------------------------------------------------------
*/
+ bool (*scan_bitmap_pagescan) (TableScanDesc scan,
+ TBMIterateResult *tbmres);
+ bool (*scan_bitmap_pagescan_next) (TableScanDesc scan,
+ TupleTableSlot *slot);
bool (*scan_sample_next_block) (TableScanDesc scan,
struct SampleScanState *scanstate);
bool (*scan_sample_next_tuple) (TableScanDesc scan,
@@ -905,6 +909,19 @@ table_estimate_size(Relation rel, int32 *attr_widths,
* ----------------------------------------------------------------------------
*/
+static inline bool
+table_scan_bitmap_pagescan(TableScanDesc scan,
+ TBMIterateResult *tbmres)
+{
+ return scan->rs_rd->rd_tableam->scan_bitmap_pagescan(scan, tbmres);
+}
+
+static inline bool
+table_scan_bitmap_pagescan_next(TableScanDesc scan, TupleTableSlot *slot)
+{
+ return scan->rs_rd->rd_tableam->scan_bitmap_pagescan_next(scan, slot);
+}
+
static inline bool
table_scan_sample_next_block(TableScanDesc scan, struct SampleScanState *scanstate)
{
--
2.21.0.dirty
--yvn3crbc4qf4vymf
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
filename="v18-0016-WIP-Move-xid-horizon-computation-for-page-level-.patch"
^ permalink raw reply [nested|flat] 33+ messages in thread
* Re: Reports on obsolete Postgres versions
@ 2024-03-11 21:12 Nathan Bossart <[email protected]>
2024-03-11 21:17 ` Re: Reports on obsolete Postgres versions Bruce Momjian <[email protected]>
0 siblings, 1 reply; 33+ messages in thread
From: Nathan Bossart @ 2024-03-11 21:12 UTC (permalink / raw)
To: Bruce Momjian <[email protected]>; +Cc: pgsql-hackers
On Mon, Mar 11, 2024 at 04:37:49PM -0400, Bruce Momjian wrote:
> https://www.postgresql.org/support/versioning/
>
> This web page should correct the idea that "upgrades are more risky than
> staying with existing versions". Is there more we can do? Should we
> have a more consistent response for such reporters?
I've read that the use of the term "minor release" can be confusing. While
the versioning page clearly describes what is eligible for a minor release,
not everyone reads it, so I suspect that many folks think there are new
features, etc. in minor releases. I think a "minor release" of Postgres is
more similar to what other projects would call a "patch version."
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
^ permalink raw reply [nested|flat] 33+ messages in thread
* Re: Reports on obsolete Postgres versions
2024-03-11 21:12 Re: Reports on obsolete Postgres versions Nathan Bossart <[email protected]>
@ 2024-03-11 21:17 ` Bruce Momjian <[email protected]>
2024-03-12 01:37 ` Re: Reports on obsolete Postgres versions Nathan Bossart <[email protected]>
2024-03-12 10:12 ` Re: Reports on obsolete Postgres versions Michael Banck <[email protected]>
0 siblings, 2 replies; 33+ messages in thread
From: Bruce Momjian @ 2024-03-11 21:17 UTC (permalink / raw)
To: Nathan Bossart <[email protected]>; +Cc: pgsql-hackers
On Mon, Mar 11, 2024 at 04:12:04PM -0500, Nathan Bossart wrote:
> On Mon, Mar 11, 2024 at 04:37:49PM -0400, Bruce Momjian wrote:
> > https://www.postgresql.org/support/versioning/
> >
> > This web page should correct the idea that "upgrades are more risky than
> > staying with existing versions". Is there more we can do? Should we
> > have a more consistent response for such reporters?
>
> I've read that the use of the term "minor release" can be confusing. While
> the versioning page clearly describes what is eligible for a minor release,
> not everyone reads it, so I suspect that many folks think there are new
> features, etc. in minor releases. I think a "minor release" of Postgres is
> more similar to what other projects would call a "patch version."
Well, we do say:
While upgrading will always contain some level of risk, PostgreSQL
minor releases fix only frequently-encountered bugs, security issues,
and data corruption problems to reduce the risk associated with
upgrading. For minor releases, the community considers not upgrading to
be riskier than upgrading.
but that is far down the page. Do we need to improve this?
--
Bruce Momjian <[email protected]> https://momjian.us
EDB https://enterprisedb.com
Only you can decide what is important to you.
^ permalink raw reply [nested|flat] 33+ messages in thread
* Re: Reports on obsolete Postgres versions
2024-03-11 21:12 Re: Reports on obsolete Postgres versions Nathan Bossart <[email protected]>
2024-03-11 21:17 ` Re: Reports on obsolete Postgres versions Bruce Momjian <[email protected]>
@ 2024-03-12 01:37 ` Nathan Bossart <[email protected]>
2024-03-12 10:00 ` Re: Reports on obsolete Postgres versions Daniel Gustafsson <[email protected]>
1 sibling, 1 reply; 33+ messages in thread
From: Nathan Bossart @ 2024-03-12 01:37 UTC (permalink / raw)
To: Bruce Momjian <[email protected]>; +Cc: pgsql-hackers
On Mon, Mar 11, 2024 at 05:17:13PM -0400, Bruce Momjian wrote:
> On Mon, Mar 11, 2024 at 04:12:04PM -0500, Nathan Bossart wrote:
>> I've read that the use of the term "minor release" can be confusing. While
>> the versioning page clearly describes what is eligible for a minor release,
>> not everyone reads it, so I suspect that many folks think there are new
>> features, etc. in minor releases. I think a "minor release" of Postgres is
>> more similar to what other projects would call a "patch version."
>
> Well, we do say:
>
> While upgrading will always contain some level of risk, PostgreSQL
> minor releases fix only frequently-encountered bugs, security issues,
> and data corruption problems to reduce the risk associated with
> upgrading. For minor releases, the community considers not upgrading to
> be riskier than upgrading.
>
> but that is far down the page. Do we need to improve this?
I think making that note more visible would certainly be an improvement.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
^ permalink raw reply [nested|flat] 33+ messages in thread
* Re: Reports on obsolete Postgres versions
2024-03-11 21:12 Re: Reports on obsolete Postgres versions Nathan Bossart <[email protected]>
2024-03-11 21:17 ` Re: Reports on obsolete Postgres versions Bruce Momjian <[email protected]>
2024-03-12 01:37 ` Re: Reports on obsolete Postgres versions Nathan Bossart <[email protected]>
@ 2024-03-12 10:00 ` Daniel Gustafsson <[email protected]>
0 siblings, 0 replies; 33+ messages in thread
From: Daniel Gustafsson @ 2024-03-12 10:00 UTC (permalink / raw)
To: Nathan Bossart <[email protected]>; +Cc: Bruce Momjian <[email protected]>; pgsql-hackers; Jonathan S. Katz <[email protected]>
> On 12 Mar 2024, at 02:37, Nathan Bossart <[email protected]> wrote:
>
> On Mon, Mar 11, 2024 at 05:17:13PM -0400, Bruce Momjian wrote:
>> On Mon, Mar 11, 2024 at 04:12:04PM -0500, Nathan Bossart wrote:
>>> I've read that the use of the term "minor release" can be confusing. While
>>> the versioning page clearly describes what is eligible for a minor release,
>>> not everyone reads it, so I suspect that many folks think there are new
>>> features, etc. in minor releases. I think a "minor release" of Postgres is
>>> more similar to what other projects would call a "patch version."
>>
>> Well, we do say:
>>
>> While upgrading will always contain some level of risk, PostgreSQL
>> minor releases fix only frequently-encountered bugs, security issues,
>> and data corruption problems to reduce the risk associated with
>> upgrading. For minor releases, the community considers not upgrading to
>> be riskier than upgrading.
>>
>> but that is far down the page. Do we need to improve this?
>
> I think making that note more visible would certainly be an improvement.
We have this almost at the top of the page, which IMHO isn't a very good
description about what a minor version is:
Each major version receives bug fixes and, if need be, security fixes
that are released at least once every three months in what we call a
"minor release."
Maybe we can rewrite that sentence to properly document what a minor is (bug
fixes *and* security fixes) with a small blurb about the upgrade risk?
(Adding Jonathan in CC: who is good at website copy).
--
Daniel Gustafsson
^ permalink raw reply [nested|flat] 33+ messages in thread
* Re: Reports on obsolete Postgres versions
2024-03-11 21:12 Re: Reports on obsolete Postgres versions Nathan Bossart <[email protected]>
2024-03-11 21:17 ` Re: Reports on obsolete Postgres versions Bruce Momjian <[email protected]>
@ 2024-03-12 10:12 ` Michael Banck <[email protected]>
2024-03-12 10:56 ` Re: Reports on obsolete Postgres versions Daniel Gustafsson <[email protected]>
1 sibling, 1 reply; 33+ messages in thread
From: Michael Banck @ 2024-03-12 10:12 UTC (permalink / raw)
To: Bruce Momjian <[email protected]>; +Cc: Nathan Bossart <[email protected]>; pgsql-hackers
Hi,
On Mon, Mar 11, 2024 at 05:17:13PM -0400, Bruce Momjian wrote:
> On Mon, Mar 11, 2024 at 04:12:04PM -0500, Nathan Bossart wrote:
> > On Mon, Mar 11, 2024 at 04:37:49PM -0400, Bruce Momjian wrote:
> > > https://www.postgresql.org/support/versioning/
> > >
> > > This web page should correct the idea that "upgrades are more risky than
> > > staying with existing versions". Is there more we can do? Should we
> > > have a more consistent response for such reporters?
> >
> > I've read that the use of the term "minor release" can be confusing. While
> > the versioning page clearly describes what is eligible for a minor release,
> > not everyone reads it, so I suspect that many folks think there are new
> > features, etc. in minor releases. I think a "minor release" of Postgres is
> > more similar to what other projects would call a "patch version."
>
> Well, we do say:
>
> While upgrading will always contain some level of risk, PostgreSQL
> minor releases fix only frequently-encountered bugs, security issues,
> and data corruption problems to reduce the risk associated with
> upgrading. For minor releases, the community considers not upgrading to
> be riskier than upgrading.
>
> but that is far down the page. Do we need to improve this?
I liked the statement from Laurenz a while ago on his blog
(paraphrased): "Upgrading to the latest patch release does not require
application testing or recertification". I am not sure we want to put
that into the official page (or maybe tone down/qualify it a bit), but I
think a lot of users stay on older minor versions because they dread
their internal testing policies.
The other thing that could maybe be made a bit better is the fantastic
patch release schedule, which however is buried in the "developer
roadmap". I can see how this was useful years ago, but I think this page
should be moved to the end-user part of the website, and maybe (also)
integrated into the support/versioning page?
Michael
^ permalink raw reply [nested|flat] 33+ messages in thread
* Re: Reports on obsolete Postgres versions
2024-03-11 21:12 Re: Reports on obsolete Postgres versions Nathan Bossart <[email protected]>
2024-03-11 21:17 ` Re: Reports on obsolete Postgres versions Bruce Momjian <[email protected]>
2024-03-12 10:12 ` Re: Reports on obsolete Postgres versions Michael Banck <[email protected]>
@ 2024-03-12 10:56 ` Daniel Gustafsson <[email protected]>
2024-03-13 16:21 ` Re: Reports on obsolete Postgres versions Jeremy Schneider <[email protected]>
2024-03-13 19:04 ` Re: Reports on obsolete Postgres versions Laurenz Albe <[email protected]>
0 siblings, 2 replies; 33+ messages in thread
From: Daniel Gustafsson @ 2024-03-12 10:56 UTC (permalink / raw)
To: Michael Banck <[email protected]>; +Cc: Bruce Momjian <[email protected]>; Nathan Bossart <[email protected]>; pgsql-hackers
>> but that is far down the page. Do we need to improve this?
> I liked the statement from Laurenz a while ago on his blog
> (paraphrased): "Upgrading to the latest patch release does not require
> application testing or recertification". I am not sure we want to put
> that into the official page (or maybe tone down/qualify it a bit), but I
> think a lot of users stay on older minor versions because they dread
> their internal testing policies.
I think we need a more conservative language since a minor release might fix a
planner bug that someone's app relied on and their plans will be worse after
upgrading. While rare, it can for sure happen so the official wording should
probably avoid such bold claims.
> The other thing that could maybe be made a bit better is the fantastic
> patch release schedule, which however is buried in the "developer
> roadmap". I can see how this was useful years ago, but I think this page
> should be moved to the end-user part of the website, and maybe (also)
> integrated into the support/versioning page?
Fair point.
--
Daniel Gustafsson
^ permalink raw reply [nested|flat] 33+ messages in thread
* Re: Reports on obsolete Postgres versions
2024-03-11 21:12 Re: Reports on obsolete Postgres versions Nathan Bossart <[email protected]>
2024-03-11 21:17 ` Re: Reports on obsolete Postgres versions Bruce Momjian <[email protected]>
2024-03-12 10:12 ` Re: Reports on obsolete Postgres versions Michael Banck <[email protected]>
2024-03-12 10:56 ` Re: Reports on obsolete Postgres versions Daniel Gustafsson <[email protected]>
@ 2024-03-13 16:21 ` Jeremy Schneider <[email protected]>
2024-03-13 17:12 ` Re: Reports on obsolete Postgres versions Bruce Momjian <[email protected]>
1 sibling, 1 reply; 33+ messages in thread
From: Jeremy Schneider @ 2024-03-13 16:21 UTC (permalink / raw)
To: Daniel Gustafsson <[email protected]>; Michael Banck <[email protected]>; +Cc: Bruce Momjian <[email protected]>; Nathan Bossart <[email protected]>; pgsql-hackers
On 3/12/24 3:56 AM, Daniel Gustafsson wrote:
>>> but that is far down the page. Do we need to improve this?
>
>> I liked the statement from Laurenz a while ago on his blog
>> (paraphrased): "Upgrading to the latest patch release does not require
>> application testing or recertification". I am not sure we want to put
>> that into the official page (or maybe tone down/qualify it a bit), but I
>> think a lot of users stay on older minor versions because they dread
>> their internal testing policies.
>
> I think we need a more conservative language since a minor release might fix a
> planner bug that someone's app relied on and their plans will be worse after
> upgrading. While rare, it can for sure happen so the official wording should
> probably avoid such bold claims.
>
>> The other thing that could maybe be made a bit better is the fantastic
>> patch release schedule, which however is buried in the "developer
>> roadmap". I can see how this was useful years ago, but I think this page
>> should be moved to the end-user part of the website, and maybe (also)
>> integrated into the support/versioning page?
>
> Fair point.
Both of the above points show inconsistency in how PG uses the terms
"minor" and "patch" today.
It's not just roadmaps and release pages where we mix up these terms
either, it's even in user-facing SQL and libpq routines: both
PQserverVersion and current_setting('server_version_num') return the
patch release version in the numeric patch field, rather than the
numeric minor field (which is always 0).
In my view, the best thing would be to move toward consistently using
the word "patch" and moving away from the word "minor" for the
PostgreSQL quarterly maintenance updates.
-Jeremy
--
http://about.me/jeremy_schneider
^ permalink raw reply [nested|flat] 33+ messages in thread
* Re: Reports on obsolete Postgres versions
2024-03-11 21:12 Re: Reports on obsolete Postgres versions Nathan Bossart <[email protected]>
2024-03-11 21:17 ` Re: Reports on obsolete Postgres versions Bruce Momjian <[email protected]>
2024-03-12 10:12 ` Re: Reports on obsolete Postgres versions Michael Banck <[email protected]>
2024-03-12 10:56 ` Re: Reports on obsolete Postgres versions Daniel Gustafsson <[email protected]>
2024-03-13 16:21 ` Re: Reports on obsolete Postgres versions Jeremy Schneider <[email protected]>
@ 2024-03-13 17:12 ` Bruce Momjian <[email protected]>
2024-03-13 18:04 ` Re: Reports on obsolete Postgres versions Robert Treat <[email protected]>
2024-03-14 15:48 ` Re: Reports on obsolete Postgres versions Peter Eisentraut <[email protected]>
0 siblings, 2 replies; 33+ messages in thread
From: Bruce Momjian @ 2024-03-13 17:12 UTC (permalink / raw)
To: Jeremy Schneider <[email protected]>; +Cc: Daniel Gustafsson <[email protected]>; Michael Banck <[email protected]>; Nathan Bossart <[email protected]>; pgsql-hackers
On Wed, Mar 13, 2024 at 09:21:27AM -0700, Jeremy Schneider wrote:
> It's not just roadmaps and release pages where we mix up these terms
> either, it's even in user-facing SQL and libpq routines: both
> PQserverVersion and current_setting('server_version_num') return the
> patch release version in the numeric patch field, rather than the
> numeric minor field (which is always 0).
>
> In my view, the best thing would be to move toward consistently using
> the word "patch" and moving away from the word "minor" for the
> PostgreSQL quarterly maintenance updates.
>
I think "minor" is a better term since it contrasts with "major". We
don't actually supply patches to upgrade minor versions.
--
Bruce Momjian <[email protected]> https://momjian.us
EDB https://enterprisedb.com
Only you can decide what is important to you.
^ permalink raw reply [nested|flat] 33+ messages in thread
* Re: Reports on obsolete Postgres versions
2024-03-11 21:12 Re: Reports on obsolete Postgres versions Nathan Bossart <[email protected]>
2024-03-11 21:17 ` Re: Reports on obsolete Postgres versions Bruce Momjian <[email protected]>
2024-03-12 10:12 ` Re: Reports on obsolete Postgres versions Michael Banck <[email protected]>
2024-03-12 10:56 ` Re: Reports on obsolete Postgres versions Daniel Gustafsson <[email protected]>
2024-03-13 16:21 ` Re: Reports on obsolete Postgres versions Jeremy Schneider <[email protected]>
2024-03-13 17:12 ` Re: Reports on obsolete Postgres versions Bruce Momjian <[email protected]>
@ 2024-03-13 18:04 ` Robert Treat <[email protected]>
2024-03-13 18:21 ` Re: Reports on obsolete Postgres versions Tom Lane <[email protected]>
2024-04-01 22:56 ` Re: Reports on obsolete Postgres versions Bruce Momjian <[email protected]>
1 sibling, 2 replies; 33+ messages in thread
From: Robert Treat @ 2024-03-13 18:04 UTC (permalink / raw)
To: Bruce Momjian <[email protected]>; +Cc: Jeremy Schneider <[email protected]>; Daniel Gustafsson <[email protected]>; Michael Banck <[email protected]>; Nathan Bossart <[email protected]>; pgsql-hackers
On Wed, Mar 13, 2024 at 1:12 PM Bruce Momjian <[email protected]> wrote:
>
> On Wed, Mar 13, 2024 at 09:21:27AM -0700, Jeremy Schneider wrote:
> > It's not just roadmaps and release pages where we mix up these terms
> > either, it's even in user-facing SQL and libpq routines: both
> > PQserverVersion and current_setting('server_version_num') return the
> > patch release version in the numeric patch field, rather than the
> > numeric minor field (which is always 0).
> >
> > In my view, the best thing would be to move toward consistently using
> > the word "patch" and moving away from the word "minor" for the
> > PostgreSQL quarterly maintenance updates.
> >
>
> I think "minor" is a better term since it contrasts with "major". We
> don't actually supply patches to upgrade minor versions.
>
I tend to agree with Bruce, and major/minor seems to be the more
common usage within the industry; iirc, debian, ubuntu, gnome, suse,
and mariadb all use that nomenclature; and ISTR some distro's who
release packaged versions of postgres with custom patches applied (ie
12.4-2 for postgres 12.4 patchlevel 2).
BTW, as a reminder, we do have this statement, in bold, in the
"upgrading" section of the versioning page:
"We always recommend that all users run the latest available minor
release for whatever major version is in use." There is actually
several other phrases and wording on that page that could probably be
propagated as replacement language in some of these other areas.
Robert Treat
https://xzilla.net
^ permalink raw reply [nested|flat] 33+ messages in thread
* Re: Reports on obsolete Postgres versions
2024-03-11 21:12 Re: Reports on obsolete Postgres versions Nathan Bossart <[email protected]>
2024-03-11 21:17 ` Re: Reports on obsolete Postgres versions Bruce Momjian <[email protected]>
2024-03-12 10:12 ` Re: Reports on obsolete Postgres versions Michael Banck <[email protected]>
2024-03-12 10:56 ` Re: Reports on obsolete Postgres versions Daniel Gustafsson <[email protected]>
2024-03-13 16:21 ` Re: Reports on obsolete Postgres versions Jeremy Schneider <[email protected]>
2024-03-13 17:12 ` Re: Reports on obsolete Postgres versions Bruce Momjian <[email protected]>
2024-03-13 18:04 ` Re: Reports on obsolete Postgres versions Robert Treat <[email protected]>
@ 2024-03-13 18:21 ` Tom Lane <[email protected]>
2024-03-13 18:29 ` Re: Reports on obsolete Postgres versions Jeremy Schneider <[email protected]>
2024-03-13 18:52 ` Re: Reports on obsolete Postgres versions Nathan Bossart <[email protected]>
1 sibling, 2 replies; 33+ messages in thread
From: Tom Lane @ 2024-03-13 18:21 UTC (permalink / raw)
To: Robert Treat <[email protected]>; +Cc: Bruce Momjian <[email protected]>; Jeremy Schneider <[email protected]>; Daniel Gustafsson <[email protected]>; Michael Banck <[email protected]>; Nathan Bossart <[email protected]>; pgsql-hackers
Robert Treat <[email protected]> writes:
> On Wed, Mar 13, 2024 at 1:12 PM Bruce Momjian <[email protected]> wrote:
>> On Wed, Mar 13, 2024 at 09:21:27AM -0700, Jeremy Schneider wrote:
>>> In my view, the best thing would be to move toward consistently using
>>> the word "patch" and moving away from the word "minor" for the
>>> PostgreSQL quarterly maintenance updates.
>> I think "minor" is a better term since it contrasts with "major". We
>> don't actually supply patches to upgrade minor versions.
> I tend to agree with Bruce, and major/minor seems to be the more
> common usage within the industry; iirc, debian, ubuntu, gnome, suse,
> and mariadb all use that nomenclature; and ISTR some distro's who
> release packaged versions of postgres with custom patches applied (ie
> 12.4-2 for postgres 12.4 patchlevel 2).
Agreed, we would probably add confusion not reduce it if we were to
change our longstanding nomenclature for this.
I'm +1 on rewriting these documentation pages though. Seems like
they could do with a whole fresh start rather than just tweaks
around the edges --- what we've got now is an accumulation of such
tweaks.
regards, tom lane
^ permalink raw reply [nested|flat] 33+ messages in thread
* Re: Reports on obsolete Postgres versions
2024-03-11 21:12 Re: Reports on obsolete Postgres versions Nathan Bossart <[email protected]>
2024-03-11 21:17 ` Re: Reports on obsolete Postgres versions Bruce Momjian <[email protected]>
2024-03-12 10:12 ` Re: Reports on obsolete Postgres versions Michael Banck <[email protected]>
2024-03-12 10:56 ` Re: Reports on obsolete Postgres versions Daniel Gustafsson <[email protected]>
2024-03-13 16:21 ` Re: Reports on obsolete Postgres versions Jeremy Schneider <[email protected]>
2024-03-13 17:12 ` Re: Reports on obsolete Postgres versions Bruce Momjian <[email protected]>
2024-03-13 18:04 ` Re: Reports on obsolete Postgres versions Robert Treat <[email protected]>
2024-03-13 18:21 ` Re: Reports on obsolete Postgres versions Tom Lane <[email protected]>
@ 2024-03-13 18:29 ` Jeremy Schneider <[email protected]>
2024-03-13 18:39 ` Re: Reports on obsolete Postgres versions Tom Lane <[email protected]>
1 sibling, 1 reply; 33+ messages in thread
From: Jeremy Schneider @ 2024-03-13 18:29 UTC (permalink / raw)
To: Tom Lane <[email protected]>; Robert Treat <[email protected]>; +Cc: Bruce Momjian <[email protected]>; Daniel Gustafsson <[email protected]>; Michael Banck <[email protected]>; Nathan Bossart <[email protected]>; pgsql-hackers
On 3/13/24 11:21 AM, Tom Lane wrote:
> Robert Treat <[email protected]> writes:
>> On Wed, Mar 13, 2024 at 1:12 PM Bruce Momjian <[email protected]> wrote:
>>> On Wed, Mar 13, 2024 at 09:21:27AM -0700, Jeremy Schneider wrote:
>>>> In my view, the best thing would be to move toward consistently using
>>>> the word "patch" and moving away from the word "minor" for the
>>>> PostgreSQL quarterly maintenance updates.
>
>>> I think "minor" is a better term since it contrasts with "major". We
>>> don't actually supply patches to upgrade minor versions.
>
>> I tend to agree with Bruce, and major/minor seems to be the more
>> common usage within the industry; iirc, debian, ubuntu, gnome, suse,
>> and mariadb all use that nomenclature; and ISTR some distro's who
>> release packaged versions of postgres with custom patches applied (ie
>> 12.4-2 for postgres 12.4 patchlevel 2).
>
> Agreed, we would probably add confusion not reduce it if we were to
> change our longstanding nomenclature for this.
"Longstanding nomenclature"??
Before v10, the quarterly maintenance updates were unambiguously and
always called patch releases
I don't understand the line of thinking here
Bruce started this whole thread because of "an increasing number of
bug/problem reports on obsolete Postgres versions"
Across the industry the word "minor" often implies a release that will
be maintained, and I'm trying to point out that the change in v10 to
change terminology from "patch" to "minor" actually might be part of
what's responsible for the increasing number of bug reports on old patch
releases, because people don't understand that patch releases are the
way those bugfixes were already delivered.
Just taking MySQL as an example, it's clear that a "minor" like 5.7 is a
full blown release that gets separate patches from 5.6 - so I don't
understand how we're making an argument it's the opposite?
-Jeremy
--
http://about.me/jeremy_schneider
^ permalink raw reply [nested|flat] 33+ messages in thread
* Re: Reports on obsolete Postgres versions
2024-03-11 21:12 Re: Reports on obsolete Postgres versions Nathan Bossart <[email protected]>
2024-03-11 21:17 ` Re: Reports on obsolete Postgres versions Bruce Momjian <[email protected]>
2024-03-12 10:12 ` Re: Reports on obsolete Postgres versions Michael Banck <[email protected]>
2024-03-12 10:56 ` Re: Reports on obsolete Postgres versions Daniel Gustafsson <[email protected]>
2024-03-13 16:21 ` Re: Reports on obsolete Postgres versions Jeremy Schneider <[email protected]>
2024-03-13 17:12 ` Re: Reports on obsolete Postgres versions Bruce Momjian <[email protected]>
2024-03-13 18:04 ` Re: Reports on obsolete Postgres versions Robert Treat <[email protected]>
2024-03-13 18:21 ` Re: Reports on obsolete Postgres versions Tom Lane <[email protected]>
2024-03-13 18:29 ` Re: Reports on obsolete Postgres versions Jeremy Schneider <[email protected]>
@ 2024-03-13 18:39 ` Tom Lane <[email protected]>
2024-03-13 18:47 ` Re: Reports on obsolete Postgres versions Jeremy Schneider <[email protected]>
0 siblings, 1 reply; 33+ messages in thread
From: Tom Lane @ 2024-03-13 18:39 UTC (permalink / raw)
To: Jeremy Schneider <[email protected]>; +Cc: Robert Treat <[email protected]>; Bruce Momjian <[email protected]>; Daniel Gustafsson <[email protected]>; Michael Banck <[email protected]>; Nathan Bossart <[email protected]>; pgsql-hackers
Jeremy Schneider <[email protected]> writes:
> On 3/13/24 11:21 AM, Tom Lane wrote:
>> Agreed, we would probably add confusion not reduce it if we were to
>> change our longstanding nomenclature for this.
> Before v10, the quarterly maintenance updates were unambiguously and
> always called patch releases
I think that's highly revisionist history. I've always called them
minor releases, and I don't recall other people using different
terminology. I believe the leadoff text on
https://www.postgresql.org/support/versioning/
is much older than when we switched from two-part major version
numbers to one-part major version numbers.
regards, tom lane
^ permalink raw reply [nested|flat] 33+ messages in thread
* Re: Reports on obsolete Postgres versions
2024-03-11 21:12 Re: Reports on obsolete Postgres versions Nathan Bossart <[email protected]>
2024-03-11 21:17 ` Re: Reports on obsolete Postgres versions Bruce Momjian <[email protected]>
2024-03-12 10:12 ` Re: Reports on obsolete Postgres versions Michael Banck <[email protected]>
2024-03-12 10:56 ` Re: Reports on obsolete Postgres versions Daniel Gustafsson <[email protected]>
2024-03-13 16:21 ` Re: Reports on obsolete Postgres versions Jeremy Schneider <[email protected]>
2024-03-13 17:12 ` Re: Reports on obsolete Postgres versions Bruce Momjian <[email protected]>
2024-03-13 18:04 ` Re: Reports on obsolete Postgres versions Robert Treat <[email protected]>
2024-03-13 18:21 ` Re: Reports on obsolete Postgres versions Tom Lane <[email protected]>
2024-03-13 18:29 ` Re: Reports on obsolete Postgres versions Jeremy Schneider <[email protected]>
2024-03-13 18:39 ` Re: Reports on obsolete Postgres versions Tom Lane <[email protected]>
@ 2024-03-13 18:47 ` Jeremy Schneider <[email protected]>
2024-04-02 09:31 ` Re: Reports on obsolete Postgres versions Magnus Hagander <[email protected]>
0 siblings, 1 reply; 33+ messages in thread
From: Jeremy Schneider @ 2024-03-13 18:47 UTC (permalink / raw)
To: Tom Lane <[email protected]>; +Cc: Robert Treat <[email protected]>; Bruce Momjian <[email protected]>; Daniel Gustafsson <[email protected]>; Michael Banck <[email protected]>; Nathan Bossart <[email protected]>; pgsql-hackers
> On Mar 13, 2024, at 11:39 AM, Tom Lane <[email protected]> wrote:
>
> Jeremy Schneider <[email protected]> writes:
>>> On 3/13/24 11:21 AM, Tom Lane wrote:
>>> Agreed, we would probably add confusion not reduce it if we were to
>>> change our longstanding nomenclature for this.
>
>> Before v10, the quarterly maintenance updates were unambiguously and
>> always called patch releases
>
> I think that's highly revisionist history. I've always called them
> minor releases, and I don't recall other people using different
> terminology. I believe the leadoff text on
>
> https://www.postgresql.org/support/versioning/
>
> is much older than when we switched from two-part major version
> numbers to one-part major version numbers.
Huh, that wasn’t what I expected. I only started (in depth) working with PG around 9.6 and I definitely thought of “6” as the minor version. This is an interesting mailing list thread.
-Jeremy
Sent from my TI-83
^ permalink raw reply [nested|flat] 33+ messages in thread
* Re: Reports on obsolete Postgres versions
2024-03-11 21:12 Re: Reports on obsolete Postgres versions Nathan Bossart <[email protected]>
2024-03-11 21:17 ` Re: Reports on obsolete Postgres versions Bruce Momjian <[email protected]>
2024-03-12 10:12 ` Re: Reports on obsolete Postgres versions Michael Banck <[email protected]>
2024-03-12 10:56 ` Re: Reports on obsolete Postgres versions Daniel Gustafsson <[email protected]>
2024-03-13 16:21 ` Re: Reports on obsolete Postgres versions Jeremy Schneider <[email protected]>
2024-03-13 17:12 ` Re: Reports on obsolete Postgres versions Bruce Momjian <[email protected]>
2024-03-13 18:04 ` Re: Reports on obsolete Postgres versions Robert Treat <[email protected]>
2024-03-13 18:21 ` Re: Reports on obsolete Postgres versions Tom Lane <[email protected]>
2024-03-13 18:29 ` Re: Reports on obsolete Postgres versions Jeremy Schneider <[email protected]>
2024-03-13 18:39 ` Re: Reports on obsolete Postgres versions Tom Lane <[email protected]>
2024-03-13 18:47 ` Re: Reports on obsolete Postgres versions Jeremy Schneider <[email protected]>
@ 2024-04-02 09:31 ` Magnus Hagander <[email protected]>
0 siblings, 0 replies; 33+ messages in thread
From: Magnus Hagander @ 2024-04-02 09:31 UTC (permalink / raw)
To: Jeremy Schneider <[email protected]>; +Cc: Tom Lane <[email protected]>; Robert Treat <[email protected]>; Bruce Momjian <[email protected]>; Daniel Gustafsson <[email protected]>; Michael Banck <[email protected]>; Nathan Bossart <[email protected]>; pgsql-hackers
On Wed, Mar 13, 2024 at 7:47 PM Jeremy Schneider <[email protected]>
wrote:
>
> > On Mar 13, 2024, at 11:39 AM, Tom Lane <[email protected]> wrote:
> >
> > Jeremy Schneider <[email protected]> writes:
> >>> On 3/13/24 11:21 AM, Tom Lane wrote:
> >>> Agreed, we would probably add confusion not reduce it if we were to
> >>> change our longstanding nomenclature for this.
> >
> >> Before v10, the quarterly maintenance updates were unambiguously and
> >> always called patch releases
> >
> > I think that's highly revisionist history. I've always called them
> > minor releases, and I don't recall other people using different
> > terminology. I believe the leadoff text on
> >
> > https://www.postgresql.org/support/versioning/
> >
> > is much older than when we switched from two-part major version
> > numbers to one-part major version numbers.
>
> Huh, that wasn’t what I expected. I only started (in depth) working with
> PG around 9.6 and I definitely thought of “6” as the minor version. This is
> an interesting mailing list thread.
>
That common misunderstanding was, in fact, one of the reasons to go to
two-part version numbers instead of 3. Because people did not realize that
the full 9.6 digit was the major version, and thus what was maintained and
such.
--
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] 33+ messages in thread
* Re: Reports on obsolete Postgres versions
2024-03-11 21:12 Re: Reports on obsolete Postgres versions Nathan Bossart <[email protected]>
2024-03-11 21:17 ` Re: Reports on obsolete Postgres versions Bruce Momjian <[email protected]>
2024-03-12 10:12 ` Re: Reports on obsolete Postgres versions Michael Banck <[email protected]>
2024-03-12 10:56 ` Re: Reports on obsolete Postgres versions Daniel Gustafsson <[email protected]>
2024-03-13 16:21 ` Re: Reports on obsolete Postgres versions Jeremy Schneider <[email protected]>
2024-03-13 17:12 ` Re: Reports on obsolete Postgres versions Bruce Momjian <[email protected]>
2024-03-13 18:04 ` Re: Reports on obsolete Postgres versions Robert Treat <[email protected]>
2024-03-13 18:21 ` Re: Reports on obsolete Postgres versions Tom Lane <[email protected]>
@ 2024-03-13 18:52 ` Nathan Bossart <[email protected]>
1 sibling, 0 replies; 33+ messages in thread
From: Nathan Bossart @ 2024-03-13 18:52 UTC (permalink / raw)
To: Tom Lane <[email protected]>; +Cc: Robert Treat <[email protected]>; Bruce Momjian <[email protected]>; Jeremy Schneider <[email protected]>; Daniel Gustafsson <[email protected]>; Michael Banck <[email protected]>; pgsql-hackers
On Wed, Mar 13, 2024 at 02:21:20PM -0400, Tom Lane wrote:
> I'm +1 on rewriting these documentation pages though. Seems like
> they could do with a whole fresh start rather than just tweaks
> around the edges --- what we've got now is an accumulation of such
> tweaks.
If no one else volunteers, I could probably give this a try once v17 is
frozen.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
^ permalink raw reply [nested|flat] 33+ messages in thread
* Re: Reports on obsolete Postgres versions
2024-03-11 21:12 Re: Reports on obsolete Postgres versions Nathan Bossart <[email protected]>
2024-03-11 21:17 ` Re: Reports on obsolete Postgres versions Bruce Momjian <[email protected]>
2024-03-12 10:12 ` Re: Reports on obsolete Postgres versions Michael Banck <[email protected]>
2024-03-12 10:56 ` Re: Reports on obsolete Postgres versions Daniel Gustafsson <[email protected]>
2024-03-13 16:21 ` Re: Reports on obsolete Postgres versions Jeremy Schneider <[email protected]>
2024-03-13 17:12 ` Re: Reports on obsolete Postgres versions Bruce Momjian <[email protected]>
2024-03-13 18:04 ` Re: Reports on obsolete Postgres versions Robert Treat <[email protected]>
@ 2024-04-01 22:56 ` Bruce Momjian <[email protected]>
2024-04-02 07:24 ` Re: Reports on obsolete Postgres versions Daniel Gustafsson <[email protected]>
1 sibling, 1 reply; 33+ messages in thread
From: Bruce Momjian @ 2024-04-01 22:56 UTC (permalink / raw)
To: Robert Treat <[email protected]>; +Cc: Jeremy Schneider <[email protected]>; Daniel Gustafsson <[email protected]>; Michael Banck <[email protected]>; Nathan Bossart <[email protected]>; pgsql-hackers
On Wed, Mar 13, 2024 at 02:04:16PM -0400, Robert Treat wrote:
> I tend to agree with Bruce, and major/minor seems to be the more
> common usage within the industry; iirc, debian, ubuntu, gnome, suse,
> and mariadb all use that nomenclature; and ISTR some distro's who
> release packaged versions of postgres with custom patches applied (ie
> 12.4-2 for postgres 12.4 patchlevel 2).
>
> BTW, as a reminder, we do have this statement, in bold, in the
> "upgrading" section of the versioning page:
> "We always recommend that all users run the latest available minor
> release for whatever major version is in use." There is actually
> several other phrases and wording on that page that could probably be
> propagated as replacement language in some of these other areas.
I ended up writing the attached doc patch. I found that some or our
text was overly-wordy, causing the impact of what we were trying to say
to be lessened. We might want to go farther than this patch, but I
think it is an improvement.
I also moved the <strong> text to the bottom of the section ---
previously, our <strong> wording referenced minor releases, then we
talked about major releases, and then minor releases. This gives a more
natural flow.
--
Bruce Momjian <[email protected]> https://momjian.us
EDB https://enterprisedb.com
Only you can decide what is important to you.
Attachments:
[text/x-diff] upgrade.diff (2.3K, ../../[email protected]/2-upgrade.diff)
download | inline diff:
diff --git a/templates/support/versioning.html b/templates/support/versioning.html
index d48e11e0..cee06954 100644
--- a/templates/support/versioning.html
+++ b/templates/support/versioning.html
@@ -45,15 +45,8 @@ number, e.g. 9.5.3 to 9.5.4.
<h2>Upgrading</h2>
<p>
- <strong>
- We always recommend that all users run the latest available minor
- release for whatever major version is in use.
- </strong>
-</p>
-
-<p>
-Major versions usually change the internal format of system tables and data
-files. These changes are often complex, so we do not maintain backward
+Major versions usually change the internal format of the system tables.
+These changes are often complex, so we do not maintain backward
compatibility of all stored data. A dump/reload of the database or use of the
<a href="/docs/current/pgupgrade.html">pg_upgrade</a> module is required
for major upgrades. We also recommend reading the
@@ -65,18 +58,25 @@ versions prior to doing so.
</p>
<p>
-Upgrading to a minor release does not normally require a dump and restore; you
-can stop the database server, install the updated binaries, and restart the
-server. For some releases, manual changes may be required to complete the
-upgrade, so always read the release notes before upgrading.
+Minor release upgrades do not require a dump and restore; you simply stop
+the database server, install the updated binaries, and restart the server.
+Such upgrades might require manual changes to complete so always read
+the release notes first.
</p>
<p>
-While upgrading will always contain some level of risk, PostgreSQL minor releases
-fix only frequently-encountered bugs, <a href="/support/security/">security</a>
-issues, and data corruption problems to reduce the risk associated with
-upgrading. For minor releases, <em>the community considers not upgrading to be
-riskier than upgrading.</em>
+Minor releases only fix frequently-encountered bugs, <a
+href="/support/security/">security</a> issues, and data corruption
+problems, so such upgrades are very low risk. <em>The community
+considers performing minor upgrades to be less risky than continuing to
+run superseded minor versions.</em>
+</p>
+
+<p>
+ <strong>
+ We recommend that users always run the latest minor release associated
+ with their major version.
+ </strong>
</p>
<h2>Releases</h2>
^ permalink raw reply [nested|flat] 33+ messages in thread
* Re: Reports on obsolete Postgres versions
2024-03-11 21:12 Re: Reports on obsolete Postgres versions Nathan Bossart <[email protected]>
2024-03-11 21:17 ` Re: Reports on obsolete Postgres versions Bruce Momjian <[email protected]>
2024-03-12 10:12 ` Re: Reports on obsolete Postgres versions Michael Banck <[email protected]>
2024-03-12 10:56 ` Re: Reports on obsolete Postgres versions Daniel Gustafsson <[email protected]>
2024-03-13 16:21 ` Re: Reports on obsolete Postgres versions Jeremy Schneider <[email protected]>
2024-03-13 17:12 ` Re: Reports on obsolete Postgres versions Bruce Momjian <[email protected]>
2024-03-13 18:04 ` Re: Reports on obsolete Postgres versions Robert Treat <[email protected]>
2024-04-01 22:56 ` Re: Reports on obsolete Postgres versions Bruce Momjian <[email protected]>
@ 2024-04-02 07:24 ` Daniel Gustafsson <[email protected]>
2024-04-02 09:34 ` Re: Reports on obsolete Postgres versions Magnus Hagander <[email protected]>
0 siblings, 1 reply; 33+ messages in thread
From: Daniel Gustafsson @ 2024-04-02 07:24 UTC (permalink / raw)
To: Bruce Momjian <[email protected]>; +Cc: Robert Treat <[email protected]>; Jeremy Schneider <[email protected]>; Michael Banck <[email protected]>; Nathan Bossart <[email protected]>; pgsql-hackers
> On 2 Apr 2024, at 00:56, Bruce Momjian <[email protected]> wrote:
> I ended up writing the attached doc patch. I found that some or our
> text was overly-wordy, causing the impact of what we were trying to say
> to be lessened. We might want to go farther than this patch, but I
> think it is an improvement.
Agreed, this is an good incremental improvement over what we have.
> I also moved the <strong> text to the bottom of the section
+1
A few small comments:
+considers performing minor upgrades to be less risky than continuing to
+run superseded minor versions.</em>
I think "superseded minor versions" could be unnecessarily complicated for
non-native speakers, I consider myself fairly used to reading english but still
had to spend a few extra (brain)cycles parsing the meaning of it in this
context.
+ We recommend that users always run the latest minor release associated
Or perhaps "current minor release" which is the term we use in the table below
on the same page?
--
Daniel Gustafsson
^ permalink raw reply [nested|flat] 33+ messages in thread
* Re: Reports on obsolete Postgres versions
2024-03-11 21:12 Re: Reports on obsolete Postgres versions Nathan Bossart <[email protected]>
2024-03-11 21:17 ` Re: Reports on obsolete Postgres versions Bruce Momjian <[email protected]>
2024-03-12 10:12 ` Re: Reports on obsolete Postgres versions Michael Banck <[email protected]>
2024-03-12 10:56 ` Re: Reports on obsolete Postgres versions Daniel Gustafsson <[email protected]>
2024-03-13 16:21 ` Re: Reports on obsolete Postgres versions Jeremy Schneider <[email protected]>
2024-03-13 17:12 ` Re: Reports on obsolete Postgres versions Bruce Momjian <[email protected]>
2024-03-13 18:04 ` Re: Reports on obsolete Postgres versions Robert Treat <[email protected]>
2024-04-01 22:56 ` Re: Reports on obsolete Postgres versions Bruce Momjian <[email protected]>
2024-04-02 07:24 ` Re: Reports on obsolete Postgres versions Daniel Gustafsson <[email protected]>
@ 2024-04-02 09:34 ` Magnus Hagander <[email protected]>
2024-04-02 20:46 ` Re: Reports on obsolete Postgres versions Bruce Momjian <[email protected]>
0 siblings, 1 reply; 33+ messages in thread
From: Magnus Hagander @ 2024-04-02 09:34 UTC (permalink / raw)
To: Daniel Gustafsson <[email protected]>; +Cc: Bruce Momjian <[email protected]>; Robert Treat <[email protected]>; Jeremy Schneider <[email protected]>; Michael Banck <[email protected]>; Nathan Bossart <[email protected]>; pgsql-hackers
On Tue, Apr 2, 2024 at 9:24 AM Daniel Gustafsson <[email protected]> wrote:
> > On 2 Apr 2024, at 00:56, Bruce Momjian <[email protected]> wrote:
>
> > I ended up writing the attached doc patch. I found that some or our
> > text was overly-wordy, causing the impact of what we were trying to say
> > to be lessened. We might want to go farther than this patch, but I
> > think it is an improvement.
>
> Agreed, this is an good incremental improvement over what we have.
>
> > I also moved the <strong> text to the bottom of the section
>
> +1
>
> A few small comments:
>
> +considers performing minor upgrades to be less risky than continuing to
> +run superseded minor versions.</em>
>
> I think "superseded minor versions" could be unnecessarily complicated for
> non-native speakers, I consider myself fairly used to reading english but
> still
> had to spend a few extra (brain)cycles parsing the meaning of it in this
> context.
>
> + We recommend that users always run the latest minor release associated
>
> Or perhaps "current minor release" which is the term we use in the table
> below
> on the same page?
>
I do like the term "current" better. It conveys (at least a bit) that we
really consider all the older ones to be, well, obsolete. The difference
"current vs obsolete" is stronger than "latest vs not quite latest".
--
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] 33+ messages in thread
* Re: Reports on obsolete Postgres versions
2024-03-11 21:12 Re: Reports on obsolete Postgres versions Nathan Bossart <[email protected]>
2024-03-11 21:17 ` Re: Reports on obsolete Postgres versions Bruce Momjian <[email protected]>
2024-03-12 10:12 ` Re: Reports on obsolete Postgres versions Michael Banck <[email protected]>
2024-03-12 10:56 ` Re: Reports on obsolete Postgres versions Daniel Gustafsson <[email protected]>
2024-03-13 16:21 ` Re: Reports on obsolete Postgres versions Jeremy Schneider <[email protected]>
2024-03-13 17:12 ` Re: Reports on obsolete Postgres versions Bruce Momjian <[email protected]>
2024-03-13 18:04 ` Re: Reports on obsolete Postgres versions Robert Treat <[email protected]>
2024-04-01 22:56 ` Re: Reports on obsolete Postgres versions Bruce Momjian <[email protected]>
2024-04-02 07:24 ` Re: Reports on obsolete Postgres versions Daniel Gustafsson <[email protected]>
2024-04-02 09:34 ` Re: Reports on obsolete Postgres versions Magnus Hagander <[email protected]>
@ 2024-04-02 20:46 ` Bruce Momjian <[email protected]>
2024-04-02 20:48 ` Re: Reports on obsolete Postgres versions Daniel Gustafsson <[email protected]>
2024-04-04 01:01 ` Re: Reports on obsolete Postgres versions David G. Johnston <[email protected]>
0 siblings, 2 replies; 33+ messages in thread
From: Bruce Momjian @ 2024-04-02 20:46 UTC (permalink / raw)
To: Magnus Hagander <[email protected]>; +Cc: Daniel Gustafsson <[email protected]>; Robert Treat <[email protected]>; Jeremy Schneider <[email protected]>; Michael Banck <[email protected]>; Nathan Bossart <[email protected]>; pgsql-hackers
On Tue, Apr 2, 2024 at 11:34:46AM +0200, Magnus Hagander wrote:
> On Tue, Apr 2, 2024 at 9:24 AM Daniel Gustafsson <[email protected]> wrote:
> A few small comments:
>
> +considers performing minor upgrades to be less risky than continuing to
> +run superseded minor versions.</em>
>
> I think "superseded minor versions" could be unnecessarily complicated for
> non-native speakers, I consider myself fairly used to reading english but
> still
> had to spend a few extra (brain)cycles parsing the meaning of it in this
> context.
>
> + We recommend that users always run the latest minor release associated
>
> Or perhaps "current minor release" which is the term we use in the table
> below
> on the same page?
>
> I do like the term "current" better. It conveys (at least a bit) that we
> really consider all the older ones to be, well, obsolete. The difference
> "current vs obsolete" is stronger than "latest vs not quite latest".
Okay, I changed "superseded" to "old", and changed "latest" to
"current", patch attached.
--
Bruce Momjian <[email protected]> https://momjian.us
EDB https://enterprisedb.com
Only you can decide what is important to you.
Attachments:
[text/x-diff] upgrade.diff (2.3K, ../../[email protected]/2-upgrade.diff)
download | inline diff:
diff --git a/templates/support/versioning.html b/templates/support/versioning.html
index d48e11e0..0ed79f4f 100644
--- a/templates/support/versioning.html
+++ b/templates/support/versioning.html
@@ -45,15 +45,8 @@ number, e.g. 9.5.3 to 9.5.4.
<h2>Upgrading</h2>
<p>
- <strong>
- We always recommend that all users run the latest available minor
- release for whatever major version is in use.
- </strong>
-</p>
-
-<p>
-Major versions usually change the internal format of system tables and data
-files. These changes are often complex, so we do not maintain backward
+Major versions usually change the internal format of the system tables.
+These changes are often complex, so we do not maintain backward
compatibility of all stored data. A dump/reload of the database or use of the
<a href="/docs/current/pgupgrade.html">pg_upgrade</a> module is required
for major upgrades. We also recommend reading the
@@ -65,18 +58,25 @@ versions prior to doing so.
</p>
<p>
-Upgrading to a minor release does not normally require a dump and restore; you
-can stop the database server, install the updated binaries, and restart the
-server. For some releases, manual changes may be required to complete the
-upgrade, so always read the release notes before upgrading.
+Minor release upgrades do not require a dump and restore; you simply stop
+the database server, install the updated binaries, and restart the server.
+Such upgrades might require manual changes to complete so always read
+the release notes first.
</p>
<p>
-While upgrading will always contain some level of risk, PostgreSQL minor releases
-fix only frequently-encountered bugs, <a href="/support/security/">security</a>
-issues, and data corruption problems to reduce the risk associated with
-upgrading. For minor releases, <em>the community considers not upgrading to be
-riskier than upgrading.</em>
+Minor releases only fix frequently-encountered bugs, <a
+href="/support/security/">security</a> issues, and data corruption
+problems, so such upgrades are very low risk. <em>The community
+considers performing minor upgrades to be less risky than continuing to
+run an old minor version.</em>
+</p>
+
+<p>
+ <strong>
+ We recommend that users always run the current minor release associated
+ with their major version.
+ </strong>
</p>
<h2>Releases</h2>
^ permalink raw reply [nested|flat] 33+ messages in thread
* Re: Reports on obsolete Postgres versions
2024-03-11 21:12 Re: Reports on obsolete Postgres versions Nathan Bossart <[email protected]>
2024-03-11 21:17 ` Re: Reports on obsolete Postgres versions Bruce Momjian <[email protected]>
2024-03-12 10:12 ` Re: Reports on obsolete Postgres versions Michael Banck <[email protected]>
2024-03-12 10:56 ` Re: Reports on obsolete Postgres versions Daniel Gustafsson <[email protected]>
2024-03-13 16:21 ` Re: Reports on obsolete Postgres versions Jeremy Schneider <[email protected]>
2024-03-13 17:12 ` Re: Reports on obsolete Postgres versions Bruce Momjian <[email protected]>
2024-03-13 18:04 ` Re: Reports on obsolete Postgres versions Robert Treat <[email protected]>
2024-04-01 22:56 ` Re: Reports on obsolete Postgres versions Bruce Momjian <[email protected]>
2024-04-02 07:24 ` Re: Reports on obsolete Postgres versions Daniel Gustafsson <[email protected]>
2024-04-02 09:34 ` Re: Reports on obsolete Postgres versions Magnus Hagander <[email protected]>
2024-04-02 20:46 ` Re: Reports on obsolete Postgres versions Bruce Momjian <[email protected]>
@ 2024-04-02 20:48 ` Daniel Gustafsson <[email protected]>
1 sibling, 0 replies; 33+ messages in thread
From: Daniel Gustafsson @ 2024-04-02 20:48 UTC (permalink / raw)
To: Bruce Momjian <[email protected]>; +Cc: Magnus Hagander <[email protected]>; Robert Treat <[email protected]>; Jeremy Schneider <[email protected]>; Michael Banck <[email protected]>; Nathan Bossart <[email protected]>; pgsql-hackers
> On 2 Apr 2024, at 22:46, Bruce Momjian <[email protected]> wrote:
> On Tue, Apr 2, 2024 at 11:34:46AM +0200, Magnus Hagander wrote:
>> I do like the term "current" better. It conveys (at least a bit) that we
>> really consider all the older ones to be, well, obsolete. The difference
>> "current vs obsolete" is stronger than "latest vs not quite latest".
>
> Okay, I changed "superseded" to "old", and changed "latest" to
> "current", patch attached.
+1, LGTM
--
Daniel Gustafsson
^ permalink raw reply [nested|flat] 33+ messages in thread
* Re: Reports on obsolete Postgres versions
2024-03-11 21:12 Re: Reports on obsolete Postgres versions Nathan Bossart <[email protected]>
2024-03-11 21:17 ` Re: Reports on obsolete Postgres versions Bruce Momjian <[email protected]>
2024-03-12 10:12 ` Re: Reports on obsolete Postgres versions Michael Banck <[email protected]>
2024-03-12 10:56 ` Re: Reports on obsolete Postgres versions Daniel Gustafsson <[email protected]>
2024-03-13 16:21 ` Re: Reports on obsolete Postgres versions Jeremy Schneider <[email protected]>
2024-03-13 17:12 ` Re: Reports on obsolete Postgres versions Bruce Momjian <[email protected]>
2024-03-13 18:04 ` Re: Reports on obsolete Postgres versions Robert Treat <[email protected]>
2024-04-01 22:56 ` Re: Reports on obsolete Postgres versions Bruce Momjian <[email protected]>
2024-04-02 07:24 ` Re: Reports on obsolete Postgres versions Daniel Gustafsson <[email protected]>
2024-04-02 09:34 ` Re: Reports on obsolete Postgres versions Magnus Hagander <[email protected]>
2024-04-02 20:46 ` Re: Reports on obsolete Postgres versions Bruce Momjian <[email protected]>
@ 2024-04-04 01:01 ` David G. Johnston <[email protected]>
2024-04-04 18:23 ` Re: Reports on obsolete Postgres versions Bruce Momjian <[email protected]>
1 sibling, 1 reply; 33+ messages in thread
From: David G. Johnston @ 2024-04-04 01:01 UTC (permalink / raw)
To: Bruce Momjian <[email protected]>; +Cc: Magnus Hagander <[email protected]>; Daniel Gustafsson <[email protected]>; Robert Treat <[email protected]>; Jeremy Schneider <[email protected]>; Michael Banck <[email protected]>; Nathan Bossart <[email protected]>; pgsql-hackers
On Tue, Apr 2, 2024 at 1:47 PM Bruce Momjian <[email protected]> wrote:
> On Tue, Apr 2, 2024 at 11:34:46AM +0200, Magnus Hagander wrote:
>
> Okay, I changed "superseded" to "old", and changed "latest" to
> "current", patch attached.
>
>
I took a pass at this and found a few items of note. Changes on top of
Bruce's patch.
diff --git a/templates/support/versioning.html
b/templates/support/versioning.html
index 0ed79f4f..d4762967 100644
--- a/templates/support/versioning.html
+++ b/templates/support/versioning.html
@@ -21,9 +21,9 @@ a release available outside of the minor release roadmap.
<p>
The PostgreSQL Global Development Group supports a major version for 5
years
-after its initial release. After its five year anniversary, a major
version will
-have one last minor release containing any fixes and will be considered
-end-of-life (EOL) and no longer supported.
+after its initial release. After its fifth anniversary, a major version
will
+have one last minor release and will be considered
+end-of-life (EOL), meaning no new bug fixes will be written for it.
</p>
# "fifth anniversary "seems more correct than "five year anniversary".
# The fact it gets a minor release implies it receives fixes.
# I've always had an issue with our use of the phrasing "no longer
supported". It seems vague when practically it just means we stop writing
patches for it. Whether individual community members refrain from
answering questions or helping people on these older releases is not a
project decision but a personal one. Also, since we already say it is
supported for 5 years it seems a bit redundant to then also say "after 5
years it is unsupported".
<h2>Version Numbering</h2>
@@ -45,11 +45,12 @@ number, e.g. 9.5.3 to 9.5.4.
<h2>Upgrading</h2>
<p>
-Major versions usually change the internal format of the system tables.
-These changes are often complex, so we do not maintain backward
-compatibility of all stored data. A dump/reload of the database or use of
the
-<a href="/docs/current/pgupgrade.html">pg_upgrade</a> module is required
-for major upgrades. We also recommend reading the
+Major versions need the data directory to be initialized so that the
system tables
+specific to that version can be created. There are two options to then
+migrate the user data from the old directory to the new one: a dump/reload
+of the database or using the
+<a href="/docs/current/pgupgrade.html">pg_upgrade</a> module.
+We also recommend reading the
<a href="/docs/current/upgrading.html">upgrading</a> section of the major
version you are planning to upgrade to. You can upgrade from one major
version
to another without upgrading to intervening versions, but we recommend
reading
@@ -58,14 +59,15 @@ versions prior to doing so.
</p>
# This still talked about "stored data" when really that isn't the main
concern and if it was pg_upgrade wouldn't work as an option.
# The choice to say "data directory" here seems reasonable if arguable.
But it implies the location of user data and we state it also contains
version-specific system tables. It can go unsaid that they are
version-specific because the collection as a whole and the layout of
individual tables can and almost certainly will change between versions.
<p>
-Minor release upgrades do not require a dump and restore; you simply stop
+Minor releases upgrades do not impact the data directory, only the
binaries.
+You simply stop
the database server, install the updated binaries, and restart the server.
-Such upgrades might require manual changes to complete so always read
+However, some upgrades might require manual changes to complete so always
read
the release notes first.
</p>
# The fact minor releases don't require dump/reload doesn't directly
preclude them from needing pg_upgrade and writing "Such upgrades" seems
like it could lead someone to think that.
# Data Directory seems generic enough to be understood here and since I
mention it in the Major Version as to why data migration is needed,
mentioning here
# as something not directly altered and thus precluding the data migration
has a nice symmetry. The potential need for manual changes becomes clearer
as well.
<p>
-Minor releases only fix frequently-encountered bugs, <a
+Minor releases only fix bugs, <a
href="/support/security/">security</a> issues, and data corruption
problems, so such upgrades are very low risk. <em>The community
considers performing minor upgrades to be less risky than continuing to
# Reality mostly boils down to trusting our judgement when it comes to bugs
as each one is evaluated individually. We do not promise to leave simply
buggy behavior alone in minor releases which is the only policy that would
nearly eliminate upgrade risk. We back-patch 5 year old bugs quite often
which by definition are not frequently encountered. I cannot think of a
good adjective to put there nor does one seem necessary even if I agree it
reads a bit odd otherwise. I think that has more to do with this being
just the wrong structure to get our point across. Can we pick out some
statistics from our long history of publishing minor releases to present an
objective reality to the reader to convince them to trust our track-record
in this matter?
David J.
^ permalink raw reply [nested|flat] 33+ messages in thread
* Re: Reports on obsolete Postgres versions
2024-03-11 21:12 Re: Reports on obsolete Postgres versions Nathan Bossart <[email protected]>
2024-03-11 21:17 ` Re: Reports on obsolete Postgres versions Bruce Momjian <[email protected]>
2024-03-12 10:12 ` Re: Reports on obsolete Postgres versions Michael Banck <[email protected]>
2024-03-12 10:56 ` Re: Reports on obsolete Postgres versions Daniel Gustafsson <[email protected]>
2024-03-13 16:21 ` Re: Reports on obsolete Postgres versions Jeremy Schneider <[email protected]>
2024-03-13 17:12 ` Re: Reports on obsolete Postgres versions Bruce Momjian <[email protected]>
2024-03-13 18:04 ` Re: Reports on obsolete Postgres versions Robert Treat <[email protected]>
2024-04-01 22:56 ` Re: Reports on obsolete Postgres versions Bruce Momjian <[email protected]>
2024-04-02 07:24 ` Re: Reports on obsolete Postgres versions Daniel Gustafsson <[email protected]>
2024-04-02 09:34 ` Re: Reports on obsolete Postgres versions Magnus Hagander <[email protected]>
2024-04-02 20:46 ` Re: Reports on obsolete Postgres versions Bruce Momjian <[email protected]>
2024-04-04 01:01 ` Re: Reports on obsolete Postgres versions David G. Johnston <[email protected]>
@ 2024-04-04 18:23 ` Bruce Momjian <[email protected]>
2024-04-04 19:27 ` Re: Reports on obsolete Postgres versions David G. Johnston <[email protected]>
0 siblings, 1 reply; 33+ messages in thread
From: Bruce Momjian @ 2024-04-04 18:23 UTC (permalink / raw)
To: David G. Johnston <[email protected]>; +Cc: Magnus Hagander <[email protected]>; Daniel Gustafsson <[email protected]>; Robert Treat <[email protected]>; Jeremy Schneider <[email protected]>; Michael Banck <[email protected]>; Nathan Bossart <[email protected]>; pgsql-hackers
On Wed, Apr 3, 2024 at 06:01:41PM -0700, David G. Johnston wrote:
> <p>
> The PostgreSQL Global Development Group supports a major version for 5 years
> -after its initial release. After its five year anniversary, a major version
> will
> -have one last minor release containing any fixes and will be considered
> -end-of-life (EOL) and no longer supported.
> +after its initial release. After its fifth anniversary, a major version will
> +have one last minor release and will be considered
> +end-of-life (EOL), meaning no new bug fixes will be written for it.
> </p>
>
> # "fifth anniversary "seems more correct than "five year anniversary".
> # The fact it gets a minor release implies it receives fixes.
> # I've always had an issue with our use of the phrasing "no longer supported".
> It seems vague when practically it just means we stop writing patches for it.
> Whether individual community members refrain from answering questions or
> helping people on these older releases is not a project decision but a personal
> one. Also, since we already say it is supported for 5 years it seems a bit
> redundant to then also say "after 5 years it is unsupported".
I went with the attached patch. I tightned up the "unsupported" part, trying to
tie it to the fact that we don't make anymore releases for it.
> <h2>Version Numbering</h2>
> @@ -45,11 +45,12 @@ number, e.g. 9.5.3 to 9.5.4.
> <h2>Upgrading</h2>
>
> <p>
> -Major versions usually change the internal format of the system tables.
> -These changes are often complex, so we do not maintain backward
> -compatibility of all stored data. A dump/reload of the database or use of the
> -<a href="/docs/current/pgupgrade.html">pg_upgrade</a> module is required
> -for major upgrades. We also recommend reading the
> +Major versions need the data directory to be initialized so that the system
> tables
> +specific to that version can be created. There are two options to then
> +migrate the user data from the old directory to the new one: a dump/reload
> +of the database or using the
> +<a href="/docs/current/pgupgrade.html">pg_upgrade</a> module.
> +We also recommend reading the
> <a href="/docs/current/upgrading.html">upgrading</a> section of the major
> version you are planning to upgrade to. You can upgrade from one major version
> to another without upgrading to intervening versions, but we recommend reading
> @@ -58,14 +59,15 @@ versions prior to doing so.
> </p>
>
> # This still talked about "stored data" when really that isn't the main concern
> and if it was pg_upgrade wouldn't work as an option.
> # The choice to say "data directory" here seems reasonable if arguable. But it
> implies the location of user data and we state it also contains
> version-specific system tables. It can go unsaid that they are
> version-specific because the collection as a whole and the layout of individual
> tables can and almost certainly will change between versions.
>
> <p>
> -Minor release upgrades do not require a dump and restore; you simply stop
> +Minor releases upgrades do not impact the data directory, only the binaries.
> +You simply stop
> the database server, install the updated binaries, and restart the server.
> -Such upgrades might require manual changes to complete so always read
> +However, some upgrades might require manual changes to complete so always read
> the release notes first.
> </p>
>
> # The fact minor releases don't require dump/reload doesn't directly preclude
> them from needing pg_upgrade and writing "Such upgrades" seems like it could
Minor upgrades never have required pg_upgrade.
> lead someone to think that.
> # Data Directory seems generic enough to be understood here and since I mention
> it in the Major Version as to why data migration is needed, mentioning here
> # as something not directly altered and thus precluding the data migration has
> a nice symmetry. The potential need for manual changes becomes clearer as
> well.
>
I decided your use of "data directory" was a better term and to combine
the first two sentences.
> <p>
> -Minor releases only fix frequently-encountered bugs, <a
> +Minor releases only fix bugs, <a
> href="/support/security/">security</a> issues, and data corruption
> problems, so such upgrades are very low risk. <em>The community
> considers performing minor upgrades to be less risky than continuing to
>
> # Reality mostly boils down to trusting our judgement when it comes to bugs as
> each one is evaluated individually. We do not promise to leave simply buggy
> behavior alone in minor releases which is the only policy that would nearly
> eliminate upgrade risk. We back-patch 5 year old bugs quite often which by
> definition are not frequently encountered. I cannot think of a good adjective
> to put there nor does one seem necessary even if I agree it reads a bit odd
> otherwise. I think that has more to do with this being just the wrong
> structure to get our point across. Can we pick out some statistics from our
> long history of publishing minor releases to present an objective reality to
> the reader to convince them to trust our track-record in this matter?
I went with frequently-encountered and low risk bugs".
Patch attached.
--
Bruce Momjian <[email protected]> https://momjian.us
EDB https://enterprisedb.com
Only you can decide what is important to you.
Attachments:
[text/x-diff] master.diff (2.9K, ../../[email protected]/2-master.diff)
download | inline diff:
diff --git a/templates/support/versioning.html b/templates/support/versioning.html
index d48e11e0..aef331a6 100644
--- a/templates/support/versioning.html
+++ b/templates/support/versioning.html
@@ -21,9 +21,8 @@ a release available outside of the minor release roadmap.
<p>
The PostgreSQL Global Development Group supports a major version for 5 years
-after its initial release. After its five year anniversary, a major version will
-have one last minor release containing any fixes and will be considered
-end-of-life (EOL) and no longer supported.
+after its initial release. After this, a final minor version will be released
+and the software will then be unsupported (end-of-life).
</p>
<h2>Version Numbering</h2>
@@ -45,16 +44,9 @@ number, e.g. 9.5.3 to 9.5.4.
<h2>Upgrading</h2>
<p>
- <strong>
- We always recommend that all users run the latest available minor
- release for whatever major version is in use.
- </strong>
-</p>
-
-<p>
-Major versions usually change the internal format of system tables and data
-files. These changes are often complex, so we do not maintain backward
-compatibility of all stored data. A dump/reload of the database or use of the
+Major versions make complex changes, so the contents of the data directory
+cannot be maintained in a backward compatible way. A dump/reload of the
+database or use of the
<a href="/docs/current/pgupgrade.html">pg_upgrade</a> module is required
for major upgrades. We also recommend reading the
<a href="/docs/current/upgrading.html">upgrading</a> section of the major
@@ -65,18 +57,25 @@ versions prior to doing so.
</p>
<p>
-Upgrading to a minor release does not normally require a dump and restore; you
-can stop the database server, install the updated binaries, and restart the
-server. For some releases, manual changes may be required to complete the
-upgrade, so always read the release notes before upgrading.
+Minor release upgrades do not require a dump and restore; you simply stop
+the database server, install the updated binaries, and restart the server.
+Such upgrades might require manual changes to complete so always read
+the release notes first.
</p>
<p>
-While upgrading will always contain some level of risk, PostgreSQL minor releases
-fix only frequently-encountered bugs, <a href="/support/security/">security</a>
-issues, and data corruption problems to reduce the risk associated with
-upgrading. For minor releases, <em>the community considers not upgrading to be
-riskier than upgrading.</em>
+Minor releases only fix frequently-encountered and low-risk bugs, <a
+href="/support/security/">security</a> issues, and data corruption
+problems, so such upgrades are very low risk. <em>The community
+considers performing minor upgrades to be less risky than continuing to
+run an old minor version.</em>
+</p>
+
+<p>
+ <strong>
+ We recommend that users always run the current minor release associated
+ with their major version.
+ </strong>
</p>
<h2>Releases</h2>
^ permalink raw reply [nested|flat] 33+ messages in thread
* Re: Reports on obsolete Postgres versions
2024-03-11 21:12 Re: Reports on obsolete Postgres versions Nathan Bossart <[email protected]>
2024-03-11 21:17 ` Re: Reports on obsolete Postgres versions Bruce Momjian <[email protected]>
2024-03-12 10:12 ` Re: Reports on obsolete Postgres versions Michael Banck <[email protected]>
2024-03-12 10:56 ` Re: Reports on obsolete Postgres versions Daniel Gustafsson <[email protected]>
2024-03-13 16:21 ` Re: Reports on obsolete Postgres versions Jeremy Schneider <[email protected]>
2024-03-13 17:12 ` Re: Reports on obsolete Postgres versions Bruce Momjian <[email protected]>
2024-03-13 18:04 ` Re: Reports on obsolete Postgres versions Robert Treat <[email protected]>
2024-04-01 22:56 ` Re: Reports on obsolete Postgres versions Bruce Momjian <[email protected]>
2024-04-02 07:24 ` Re: Reports on obsolete Postgres versions Daniel Gustafsson <[email protected]>
2024-04-02 09:34 ` Re: Reports on obsolete Postgres versions Magnus Hagander <[email protected]>
2024-04-02 20:46 ` Re: Reports on obsolete Postgres versions Bruce Momjian <[email protected]>
2024-04-04 01:01 ` Re: Reports on obsolete Postgres versions David G. Johnston <[email protected]>
2024-04-04 18:23 ` Re: Reports on obsolete Postgres versions Bruce Momjian <[email protected]>
@ 2024-04-04 19:27 ` David G. Johnston <[email protected]>
0 siblings, 0 replies; 33+ messages in thread
From: David G. Johnston @ 2024-04-04 19:27 UTC (permalink / raw)
To: Bruce Momjian <[email protected]>; +Cc: Magnus Hagander <[email protected]>; Daniel Gustafsson <[email protected]>; Robert Treat <[email protected]>; Jeremy Schneider <[email protected]>; Michael Banck <[email protected]>; Nathan Bossart <[email protected]>; pgsql-hackers
On Thu, Apr 4, 2024 at 11:23 AM Bruce Momjian <[email protected]> wrote:
> On Wed, Apr 3, 2024 at 06:01:41PM -0700, David G. Johnston wrote:
> > <p>
> > The PostgreSQL Global Development Group supports a major version for 5
> years
> > -after its initial release. After its five year anniversary, a major
> version
> > will
> > -have one last minor release containing any fixes and will be considered
> > -end-of-life (EOL) and no longer supported.
> > +after its initial release. After its fifth anniversary, a major version
> will
> > +have one last minor release and will be considered
> > +end-of-life (EOL), meaning no new bug fixes will be written for it.
> > </p>
> >
> > # "fifth anniversary "seems more correct than "five year anniversary".
> > # The fact it gets a minor release implies it receives fixes.
> > # I've always had an issue with our use of the phrasing "no longer
> supported".
> > It seems vague when practically it just means we stop writing patches
> for it.
> > Whether individual community members refrain from answering questions or
> > helping people on these older releases is not a project decision but a
> personal
> > one. Also, since we already say it is supported for 5 years it seems a
> bit
> > redundant to then also say "after 5 years it is unsupported".
>
> I went with the attached patch. I tightned up the "unsupported" part,
> trying to
> tie it to the fact that we don't make anymore releases for it.
>
> > <h2>Version Numbering</h2>
> > @@ -45,11 +45,12 @@ number, e.g. 9.5.3 to 9.5.4.
> > <h2>Upgrading</h2>
> >
> > <p>
> > -Major versions usually change the internal format of the system tables.
> > -These changes are often complex, so we do not maintain backward
> > -compatibility of all stored data. A dump/reload of the database or use
> of the
> > -<a href="/docs/current/pgupgrade.html">pg_upgrade</a> module is required
> > -for major upgrades. We also recommend reading the
> > +Major versions need the data directory to be initialized so that the
> system
> > tables
> > +specific to that version can be created. There are two options to then
> > +migrate the user data from the old directory to the new one: a
> dump/reload
> > +of the database or using the
> > +<a href="/docs/current/pgupgrade.html">pg_upgrade</a> module.
> > +We also recommend reading the
> > <a href="/docs/current/upgrading.html">upgrading</a> section of the
> major
> > version you are planning to upgrade to. You can upgrade from one major
> version
> > to another without upgrading to intervening versions, but we recommend
> reading
> > @@ -58,14 +59,15 @@ versions prior to doing so.
> > </p>
> >
> > # This still talked about "stored data" when really that isn't the main
> concern
> > and if it was pg_upgrade wouldn't work as an option.
> > # The choice to say "data directory" here seems reasonable if arguable.
> But it
> > implies the location of user data and we state it also contains
> > version-specific system tables. It can go unsaid that they are
> > version-specific because the collection as a whole and the layout of
> individual
> > tables can and almost certainly will change between versions.
> >
> > <p>
> > -Minor release upgrades do not require a dump and restore; you simply
> stop
> > +Minor releases upgrades do not impact the data directory, only the
> binaries.
> > +You simply stop
> > the database server, install the updated binaries, and restart the
> server.
> > -Such upgrades might require manual changes to complete so always read
> > +However, some upgrades might require manual changes to complete so
> always read
> > the release notes first.
> > </p>
> >
> > # The fact minor releases don't require dump/reload doesn't directly
> preclude
> > them from needing pg_upgrade and writing "Such upgrades" seems like it
> could
>
> Minor upgrades never have required pg_upgrade.
>
>
How about this:
"""
Major versions make complex changes, so the contents of the data directory
cannot be maintained in a backward compatible way. A dump and restore of
the databases is required, either done manually or as part of running the
<a href="/docs/current/pgupgrade.html">pg_upgrade</a> server application.
"""
My main change here is to mirror "dump and restore" in both paragraphs and
make it clear that this action is required and that the unnamed
pg_dump/pg_restore tools or pg_upgrade are used in order to perform this
task. Since minor version upgrades do not require "dump and restore" they
need not use these tools.
Also, calling pg_upgrade a module doesn't seem correct. It is found under
server applications in our docs and consists solely of that program (and a
bunch of manual steps) from the user's perspective.
David J.
^ permalink raw reply [nested|flat] 33+ messages in thread
* Re: Reports on obsolete Postgres versions
2024-03-11 21:12 Re: Reports on obsolete Postgres versions Nathan Bossart <[email protected]>
2024-03-11 21:17 ` Re: Reports on obsolete Postgres versions Bruce Momjian <[email protected]>
2024-03-12 10:12 ` Re: Reports on obsolete Postgres versions Michael Banck <[email protected]>
2024-03-12 10:56 ` Re: Reports on obsolete Postgres versions Daniel Gustafsson <[email protected]>
2024-03-13 16:21 ` Re: Reports on obsolete Postgres versions Jeremy Schneider <[email protected]>
2024-03-13 17:12 ` Re: Reports on obsolete Postgres versions Bruce Momjian <[email protected]>
@ 2024-03-14 15:48 ` Peter Eisentraut <[email protected]>
2024-03-15 10:17 ` Re: Reports on obsolete Postgres versions Daniel Gustafsson <[email protected]>
1 sibling, 1 reply; 33+ messages in thread
From: Peter Eisentraut @ 2024-03-14 15:48 UTC (permalink / raw)
To: Bruce Momjian <[email protected]>; Jeremy Schneider <[email protected]>; +Cc: Daniel Gustafsson <[email protected]>; Michael Banck <[email protected]>; Nathan Bossart <[email protected]>; pgsql-hackers
On 13.03.24 18:12, Bruce Momjian wrote:
> On Wed, Mar 13, 2024 at 09:21:27AM -0700, Jeremy Schneider wrote:
>> It's not just roadmaps and release pages where we mix up these terms
>> either, it's even in user-facing SQL and libpq routines: both
>> PQserverVersion and current_setting('server_version_num') return the
>> patch release version in the numeric patch field, rather than the
>> numeric minor field (which is always 0).
>>
>> In my view, the best thing would be to move toward consistently using
>> the word "patch" and moving away from the word "minor" for the
>> PostgreSQL quarterly maintenance updates.
>
> I think "minor" is a better term since it contrasts with "major". We
> don't actually supply patches to upgrade minor versions.
There are potentially different adjectives that could apply to "version"
and "release".
The version numbers can be called major and minor, because that just
describes their ordering and significance.
But I do agree that "minor release" isn't quite as clear, because one
could also interpret that as "a release, but a bit smaller this time".
(Also might not translate well, since "minor" and "small" could
translate to the same thing.)
One could instead, for example, describe those as "maintenance releases":
"Are you on the latest maintenance release? Why not? Are you not
maintaining your database?"
That carries much more urgency than the same with "minor".
A maintenance release corresponds to an increase in the minor version
number. It's still tied together, but has different terminology.
The last news item reads:
"The PostgreSQL Global Development Group has released an update to all
supported versions of PostgreSQL"
which has no urgency, but consider
"The PostgreSQL Global Development Group has published maintenance
releases to all supported versions of PostgreSQL"
^ permalink raw reply [nested|flat] 33+ messages in thread
* Re: Reports on obsolete Postgres versions
2024-03-11 21:12 Re: Reports on obsolete Postgres versions Nathan Bossart <[email protected]>
2024-03-11 21:17 ` Re: Reports on obsolete Postgres versions Bruce Momjian <[email protected]>
2024-03-12 10:12 ` Re: Reports on obsolete Postgres versions Michael Banck <[email protected]>
2024-03-12 10:56 ` Re: Reports on obsolete Postgres versions Daniel Gustafsson <[email protected]>
2024-03-13 16:21 ` Re: Reports on obsolete Postgres versions Jeremy Schneider <[email protected]>
2024-03-13 17:12 ` Re: Reports on obsolete Postgres versions Bruce Momjian <[email protected]>
2024-03-14 15:48 ` Re: Reports on obsolete Postgres versions Peter Eisentraut <[email protected]>
@ 2024-03-15 10:17 ` Daniel Gustafsson <[email protected]>
2024-03-15 16:14 ` Re: Reports on obsolete Postgres versions Michael Banck <[email protected]>
2024-03-15 16:48 ` Re: Reports on obsolete Postgres versions Jeremy Schneider <[email protected]>
0 siblings, 2 replies; 33+ messages in thread
From: Daniel Gustafsson @ 2024-03-15 10:17 UTC (permalink / raw)
To: Peter Eisentraut <[email protected]>; +Cc: Bruce Momjian <[email protected]>; Jeremy Schneider <[email protected]>; Michael Banck <[email protected]>; Nathan Bossart <[email protected]>; pgsql-hackers
> On 14 Mar 2024, at 16:48, Peter Eisentraut <[email protected]> wrote:
> On 13.03.24 18:12, Bruce Momjian wrote:
>> I think "minor" is a better term since it contrasts with "major". We
>> don't actually supply patches to upgrade minor versions.
>
> There are potentially different adjectives that could apply to "version" and "release".
>
> The version numbers can be called major and minor, because that just describes their ordering and significance.
>
> But I do agree that "minor release" isn't quite as clear, because one could also interpret that as "a release, but a bit smaller this time". (Also might not translate well, since "minor" and "small" could translate to the same thing.)
Some of the user confusion likely stems from us using the same nomenclature as
SemVer, but for different things. SemVer has become very widely adopted, to
the point where it's almost assumed by many, so maybe we need to explicitly
state that we *don't* use SemVer (we don't mention that anywhere in the docs or
on the website).
> One could instead, for example, describe those as "maintenance releases":
That might indeed be a better name for what we provide.
--
Daniel Gustafsson
^ permalink raw reply [nested|flat] 33+ messages in thread
* Re: Reports on obsolete Postgres versions
2024-03-11 21:12 Re: Reports on obsolete Postgres versions Nathan Bossart <[email protected]>
2024-03-11 21:17 ` Re: Reports on obsolete Postgres versions Bruce Momjian <[email protected]>
2024-03-12 10:12 ` Re: Reports on obsolete Postgres versions Michael Banck <[email protected]>
2024-03-12 10:56 ` Re: Reports on obsolete Postgres versions Daniel Gustafsson <[email protected]>
2024-03-13 16:21 ` Re: Reports on obsolete Postgres versions Jeremy Schneider <[email protected]>
2024-03-13 17:12 ` Re: Reports on obsolete Postgres versions Bruce Momjian <[email protected]>
2024-03-14 15:48 ` Re: Reports on obsolete Postgres versions Peter Eisentraut <[email protected]>
2024-03-15 10:17 ` Re: Reports on obsolete Postgres versions Daniel Gustafsson <[email protected]>
@ 2024-03-15 16:14 ` Michael Banck <[email protected]>
1 sibling, 0 replies; 33+ messages in thread
From: Michael Banck @ 2024-03-15 16:14 UTC (permalink / raw)
To: Daniel Gustafsson <[email protected]>; +Cc: Peter Eisentraut <[email protected]>; Bruce Momjian <[email protected]>; Jeremy Schneider <[email protected]>; Nathan Bossart <[email protected]>; pgsql-hackers
On Fri, Mar 15, 2024 at 11:17:53AM +0100, Daniel Gustafsson wrote:
> > On 14 Mar 2024, at 16:48, Peter Eisentraut <[email protected]> wrote:
> > One could instead, for example, describe those as "maintenance releases":
>
> That might indeed be a better name for what we provide.
+1
^ permalink raw reply [nested|flat] 33+ messages in thread
* Re: Reports on obsolete Postgres versions
2024-03-11 21:12 Re: Reports on obsolete Postgres versions Nathan Bossart <[email protected]>
2024-03-11 21:17 ` Re: Reports on obsolete Postgres versions Bruce Momjian <[email protected]>
2024-03-12 10:12 ` Re: Reports on obsolete Postgres versions Michael Banck <[email protected]>
2024-03-12 10:56 ` Re: Reports on obsolete Postgres versions Daniel Gustafsson <[email protected]>
2024-03-13 16:21 ` Re: Reports on obsolete Postgres versions Jeremy Schneider <[email protected]>
2024-03-13 17:12 ` Re: Reports on obsolete Postgres versions Bruce Momjian <[email protected]>
2024-03-14 15:48 ` Re: Reports on obsolete Postgres versions Peter Eisentraut <[email protected]>
2024-03-15 10:17 ` Re: Reports on obsolete Postgres versions Daniel Gustafsson <[email protected]>
@ 2024-03-15 16:48 ` Jeremy Schneider <[email protected]>
1 sibling, 0 replies; 33+ messages in thread
From: Jeremy Schneider @ 2024-03-15 16:48 UTC (permalink / raw)
To: Daniel Gustafsson <[email protected]>; Peter Eisentraut <[email protected]>; +Cc: Bruce Momjian <[email protected]>; Michael Banck <[email protected]>; Nathan Bossart <[email protected]>; pgsql-hackers
On 3/15/24 3:17 AM, Daniel Gustafsson wrote:
>> On 14 Mar 2024, at 16:48, Peter Eisentraut <[email protected]> wrote:
>> On 13.03.24 18:12, Bruce Momjian wrote:
>
>>> I think "minor" is a better term since it contrasts with "major". We
>>> don't actually supply patches to upgrade minor versions.
>>
>> There are potentially different adjectives that could apply to "version" and "release".
>>
>> The version numbers can be called major and minor, because that just describes their ordering and significance.
>>
>> But I do agree that "minor release" isn't quite as clear, because one could also interpret that as "a release, but a bit smaller this time". (Also might not translate well, since "minor" and "small" could translate to the same thing.)
>
> Some of the user confusion likely stems from us using the same nomenclature as
> SemVer, but for different things. SemVer has become very widely adopted, to
> the point where it's almost assumed by many, so maybe we need to explicitly
> state that we *don't* use SemVer (we don't mention that anywhere in the docs or
> on the website).
Semantic Versioning was definitely part of what led to my confusion
up-thread here. I was also mistaken in what I said up-thread about
MySQL, who also calls "5.7" the "major" version.
>> One could instead, for example, describe those as "maintenance releases":
>
> That might indeed be a better name for what we provide.
The latest PostgreSQL news item uses the word "update" and seems pretty
well written in this area already (at least to me)
Also I just confirmed, the bug reporting form also seems well written:
"Make sure you are running the latest available minor release for your
major version before reporting a bug. The current list of supported
versions is 16.2, 15.6, 14.11, 13.14, 12.18."
This all looks good, but I do still agree that a gradual shift toward
saying "maintenance update" instead of "minor" might still promote more
clarity in the long run?
-Jeremy
--
http://about.me/jeremy_schneider
^ permalink raw reply [nested|flat] 33+ messages in thread
* Re: Reports on obsolete Postgres versions
2024-03-11 21:12 Re: Reports on obsolete Postgres versions Nathan Bossart <[email protected]>
2024-03-11 21:17 ` Re: Reports on obsolete Postgres versions Bruce Momjian <[email protected]>
2024-03-12 10:12 ` Re: Reports on obsolete Postgres versions Michael Banck <[email protected]>
2024-03-12 10:56 ` Re: Reports on obsolete Postgres versions Daniel Gustafsson <[email protected]>
@ 2024-03-13 19:04 ` Laurenz Albe <[email protected]>
2024-03-14 14:15 ` Re: Reports on obsolete Postgres versions Robert Haas <[email protected]>
1 sibling, 1 reply; 33+ messages in thread
From: Laurenz Albe @ 2024-03-13 19:04 UTC (permalink / raw)
To: Daniel Gustafsson <[email protected]>; Michael Banck <[email protected]>; +Cc: Bruce Momjian <[email protected]>; Nathan Bossart <[email protected]>; pgsql-hackers
On Tue, 2024-03-12 at 11:56 +0100, Daniel Gustafsson wrote:
> > I liked the statement from Laurenz a while ago on his blog
> > (paraphrased): "Upgrading to the latest patch release does not require
> > application testing or recertification". I am not sure we want to put
> > that into the official page (or maybe tone down/qualify it a bit), but I
> > think a lot of users stay on older minor versions because they dread
> > their internal testing policies.
>
> I think we need a more conservative language since a minor release might fix a
> planner bug that someone's app relied on and their plans will be worse after
> upgrading. While rare, it can for sure happen so the official wording should
> probably avoid such bold claims.
I think we are pretty conservative with backpatching changes to the
optimizer that could destabilize existing plans.
I feel quite strongly that we should not use overly conservative language
there. If people feel that they have to test their applications for new
minor releases, the only effect will be that they won't install minor releases.
Installing a minor release should be as routine as the operating system
patches that many companies apply automatically during weekend maintenance
windows. They can also introduce bugs, and everybody knows and accepts that.
Yours,
Laurenz Albe
^ permalink raw reply [nested|flat] 33+ messages in thread
* Re: Reports on obsolete Postgres versions
2024-03-11 21:12 Re: Reports on obsolete Postgres versions Nathan Bossart <[email protected]>
2024-03-11 21:17 ` Re: Reports on obsolete Postgres versions Bruce Momjian <[email protected]>
2024-03-12 10:12 ` Re: Reports on obsolete Postgres versions Michael Banck <[email protected]>
2024-03-12 10:56 ` Re: Reports on obsolete Postgres versions Daniel Gustafsson <[email protected]>
2024-03-13 19:04 ` Re: Reports on obsolete Postgres versions Laurenz Albe <[email protected]>
@ 2024-03-14 14:15 ` Robert Haas <[email protected]>
2024-03-15 02:46 ` Re: Reports on obsolete Postgres versions Bruce Momjian <[email protected]>
0 siblings, 1 reply; 33+ messages in thread
From: Robert Haas @ 2024-03-14 14:15 UTC (permalink / raw)
To: Laurenz Albe <[email protected]>; +Cc: Daniel Gustafsson <[email protected]>; Michael Banck <[email protected]>; Bruce Momjian <[email protected]>; Nathan Bossart <[email protected]>; pgsql-hackers
On Wed, Mar 13, 2024 at 3:05 PM Laurenz Albe <[email protected]> wrote:
> I think we are pretty conservative with backpatching changes to the
> optimizer that could destabilize existing plans.
We have gotten better about that, which is good.
> I feel quite strongly that we should not use overly conservative language
> there. If people feel that they have to test their applications for new
> minor releases, the only effect will be that they won't install minor releases.
> Installing a minor release should be as routine as the operating system
> patches that many companies apply automatically during weekend maintenance
> windows. They can also introduce bugs, and everybody knows and accepts that.
I don't agree with this. If we tell people that they don't need to
test their applications after an upgrade, I do not think that the
result will be that they skip the testing and everything works
perfectly. I think that the result will be that we lose all
credibility. Nobody who has been working on computers for longer than
a week is going to believe that a software upgrade can't break
anything, and someone whose entire business depends on things not
breaking is going to want to validate that they haven't. And they're
not wrong to think that way, either.
I think that whatever we say here should focus on what we try to do or
guarantee, not on what actions we think users ought to take, never
mind must take. We can say that we try to avoid making any changes
upon which an application might be relying -- but there surely is some
weasel-wording there, because we have made such changes before in the
name of security, and sometimes to fix bugs, and we will likely to do
so again in the future. But it's not for us to decide how much testing
is warranted. It's the user's system, not ours.
In the end, while I certainly don't mind improving the web page, I
think that a lot of what we're seeing here probably has to do with the
growing popularity and success of PostgreSQL. If you have more people
using your software, you're also going to have more people using
out-of-date versions of your software.
--
Robert Haas
EDB: http://www.enterprisedb.com
^ permalink raw reply [nested|flat] 33+ messages in thread
* Re: Reports on obsolete Postgres versions
2024-03-11 21:12 Re: Reports on obsolete Postgres versions Nathan Bossart <[email protected]>
2024-03-11 21:17 ` Re: Reports on obsolete Postgres versions Bruce Momjian <[email protected]>
2024-03-12 10:12 ` Re: Reports on obsolete Postgres versions Michael Banck <[email protected]>
2024-03-12 10:56 ` Re: Reports on obsolete Postgres versions Daniel Gustafsson <[email protected]>
2024-03-13 19:04 ` Re: Reports on obsolete Postgres versions Laurenz Albe <[email protected]>
2024-03-14 14:15 ` Re: Reports on obsolete Postgres versions Robert Haas <[email protected]>
@ 2024-03-15 02:46 ` Bruce Momjian <[email protected]>
2024-03-15 02:50 ` Re: Reports on obsolete Postgres versions Bruce Momjian <[email protected]>
0 siblings, 1 reply; 33+ messages in thread
From: Bruce Momjian @ 2024-03-15 02:46 UTC (permalink / raw)
To: Robert Haas <[email protected]>; +Cc: Laurenz Albe <[email protected]>; Daniel Gustafsson <[email protected]>; Michael Banck <[email protected]>; Nathan Bossart <[email protected]>; pgsql-hackers
On Thu, Mar 14, 2024 at 10:15:18AM -0400, Robert Haas wrote:
> I think that whatever we say here should focus on what we try to do or
> guarantee, not on what actions we think users ought to take, never
> mind must take. We can say that we try to avoid making any changes
> upon which an application might be relying -- but there surely is some
> weasel-wording there, because we have made such changes before in the
> name of security, and sometimes to fix bugs, and we will likely to do
> so again in the future. But it's not for us to decide how much testing
> is warranted. It's the user's system, not ours.
Yes, good point, let's tell whem what our goals are and they can decide
what testing they need.
> In the end, while I certainly don't mind improving the web page, I
> think that a lot of what we're seeing here probably has to do with the
> growing popularity and success of PostgreSQL. If you have more people
> using your software, you're also going to have more people using
> out-of-date versions of your software.
Yeah, probably, and we recently end-of-life'ed PG 11.
--
Bruce Momjian <[email protected]> https://momjian.us
EDB https://enterprisedb.com
Only you can decide what is important to you.
^ permalink raw reply [nested|flat] 33+ messages in thread
* Re: Reports on obsolete Postgres versions
2024-03-11 21:12 Re: Reports on obsolete Postgres versions Nathan Bossart <[email protected]>
2024-03-11 21:17 ` Re: Reports on obsolete Postgres versions Bruce Momjian <[email protected]>
2024-03-12 10:12 ` Re: Reports on obsolete Postgres versions Michael Banck <[email protected]>
2024-03-12 10:56 ` Re: Reports on obsolete Postgres versions Daniel Gustafsson <[email protected]>
2024-03-13 19:04 ` Re: Reports on obsolete Postgres versions Laurenz Albe <[email protected]>
2024-03-14 14:15 ` Re: Reports on obsolete Postgres versions Robert Haas <[email protected]>
2024-03-15 02:46 ` Re: Reports on obsolete Postgres versions Bruce Momjian <[email protected]>
@ 2024-03-15 02:50 ` Bruce Momjian <[email protected]>
0 siblings, 0 replies; 33+ messages in thread
From: Bruce Momjian @ 2024-03-15 02:50 UTC (permalink / raw)
To: Robert Haas <[email protected]>; +Cc: Laurenz Albe <[email protected]>; Daniel Gustafsson <[email protected]>; Michael Banck <[email protected]>; Nathan Bossart <[email protected]>; pgsql-hackers
On Thu, Mar 14, 2024 at 10:46:28PM -0400, Bruce Momjian wrote:
> > In the end, while I certainly don't mind improving the web page, I
> > think that a lot of what we're seeing here probably has to do with the
> > growing popularity and success of PostgreSQL. If you have more people
> > using your software, you're also going to have more people using
> > out-of-date versions of your software.
>
> Yeah, probably, and we recently end-of-life'ed PG 11.
In a way it is that we had more users during the PG 10/11 period than
before that, and those people aren't upgrading as quickly.
--
Bruce Momjian <[email protected]> https://momjian.us
EDB https://enterprisedb.com
Only you can decide what is important to you.
^ permalink raw reply [nested|flat] 33+ messages in thread
* [PATCH v16 1/8] Row pattern recognition patch for raw parser.
@ 2024-04-12 06:49 Tatsuo Ishii <[email protected]>
0 siblings, 0 replies; 33+ messages in thread
From: Tatsuo Ishii @ 2024-04-12 06:49 UTC (permalink / raw)
---
src/backend/parser/gram.y | 221 ++++++++++++++++++++++++++++++--
src/include/nodes/parsenodes.h | 67 ++++++++++
src/include/parser/kwlist.h | 8 ++
src/include/parser/parse_node.h | 1 +
4 files changed, 285 insertions(+), 12 deletions(-)
diff --git a/src/backend/parser/gram.y b/src/backend/parser/gram.y
index 0523f7e891..8837fd4fa1 100644
--- a/src/backend/parser/gram.y
+++ b/src/backend/parser/gram.y
@@ -680,6 +680,21 @@ static Node *makeRecursiveViewSelect(char *relname, List *aliases, Node *query);
json_object_constructor_null_clause_opt
json_array_constructor_null_clause_opt
+%type <target> row_pattern_measure_item
+ row_pattern_definition
+%type <node> opt_row_pattern_common_syntax
+ opt_row_pattern_skip_to
+ row_pattern_subset_item
+ row_pattern_term
+%type <list> opt_row_pattern_measures
+ row_pattern_measure_list
+ row_pattern_definition_list
+ opt_row_pattern_subset_clause
+ row_pattern_subset_list
+ row_pattern_subset_rhs
+ row_pattern
+%type <boolean> opt_row_pattern_initial_or_seek
+ first_or_last
/*
* Non-keyword token types. These are hard-wired into the "flex" lexer.
@@ -723,7 +738,7 @@ static Node *makeRecursiveViewSelect(char *relname, List *aliases, Node *query);
CURRENT_TIME CURRENT_TIMESTAMP CURRENT_USER CURSOR CYCLE
DATA_P DATABASE DAY_P DEALLOCATE DEC DECIMAL_P DECLARE DEFAULT DEFAULTS
- DEFERRABLE DEFERRED DEFINER DELETE_P DELIMITER DELIMITERS DEPENDS DEPTH DESC
+ DEFERRABLE DEFERRED DEFINE DEFINER DELETE_P DELIMITER DELIMITERS DEPENDS DEPTH DESC
DETACH DICTIONARY DISABLE_P DISCARD DISTINCT DO DOCUMENT_P DOMAIN_P
DOUBLE_P DROP
@@ -739,7 +754,7 @@ static Node *makeRecursiveViewSelect(char *relname, List *aliases, Node *query);
HANDLER HAVING HEADER_P HOLD HOUR_P
IDENTITY_P IF_P ILIKE IMMEDIATE IMMUTABLE IMPLICIT_P IMPORT_P IN_P INCLUDE
- INCLUDING INCREMENT INDENT INDEX INDEXES INHERIT INHERITS INITIALLY INLINE_P
+ INCLUDING INCREMENT INDENT INDEX INDEXES INHERIT INHERITS INITIAL INITIALLY INLINE_P
INNER_P INOUT INPUT_P INSENSITIVE INSERT INSTEAD INT_P INTEGER
INTERSECT INTERVAL INTO INVOKER IS ISNULL ISOLATION
@@ -752,7 +767,7 @@ static Node *makeRecursiveViewSelect(char *relname, List *aliases, Node *query);
LEADING LEAKPROOF LEAST LEFT LEVEL LIKE LIMIT LISTEN LOAD LOCAL
LOCALTIME LOCALTIMESTAMP LOCATION LOCK_P LOCKED LOGGED
- MAPPING MATCH MATCHED MATERIALIZED MAXVALUE MERGE MERGE_ACTION METHOD
+ MAPPING MATCH MATCHED MATERIALIZED MAXVALUE MEASURES MERGE MERGE_ACTION METHOD
MINUTE_P MINVALUE MODE MONTH_P MOVE
NAME_P NAMES NATIONAL NATURAL NCHAR NESTED NEW NEXT NFC NFD NFKC NFKD NO
@@ -764,9 +779,8 @@ static Node *makeRecursiveViewSelect(char *relname, List *aliases, Node *query);
ORDER ORDINALITY OTHERS OUT_P OUTER_P
OVER OVERLAPS OVERLAY OVERRIDING OWNED OWNER
- PARALLEL PARAMETER PARSER PARTIAL PARTITION PARTITIONS PASSING PASSWORD PATH
- PERIOD PLACING PLAN PLANS POLICY
-
+ PARALLEL PARAMETER PARSER PARTIAL PARTITION PARTITIONS PASSING PASSWORD PAST
+ PATH PATTERN_P PERIOD PERMUTE PLACING PLAN PLANS POLICY
POSITION PRECEDING PRECISION PRESERVE PREPARE PREPARED PRIMARY
PRIOR PRIVILEGES PROCEDURAL PROCEDURE PROCEDURES PROGRAM PUBLICATION
@@ -777,12 +791,13 @@ static Node *makeRecursiveViewSelect(char *relname, List *aliases, Node *query);
RESET RESTART RESTRICT RETURN RETURNING RETURNS REVOKE RIGHT ROLE ROLLBACK ROLLUP
ROUTINE ROUTINES ROW ROWS RULE
- SAVEPOINT SCALAR SCHEMA SCHEMAS SCROLL SEARCH SECOND_P SECURITY SELECT
+ SAVEPOINT SCALAR SCHEMA SCHEMAS SCROLL SEARCH SECOND_P SECURITY SEEK SELECT
SEQUENCE SEQUENCES
+
SERIALIZABLE SERVER SESSION SESSION_USER SET SETS SETOF SHARE SHOW
SIMILAR SIMPLE SKIP SMALLINT SNAPSHOT SOME SPLIT SOURCE SQL_P STABLE STANDALONE_P
START STATEMENT STATISTICS STDIN STDOUT STORAGE STORED STRICT_P STRING_P STRIP_P
- SUBSCRIPTION SUBSTRING SUPPORT SYMMETRIC SYSID SYSTEM_P SYSTEM_USER
+ SUBSCRIPTION SUBSET SUBSTRING SUPPORT SYMMETRIC SYSID SYSTEM_P SYSTEM_USER
TABLE TABLES TABLESAMPLE TABLESPACE TARGET TEMP TEMPLATE TEMPORARY TEXT_P THEN
TIES TIME TIMESTAMP TO TRAILING TRANSACTION TRANSFORM
@@ -891,6 +906,7 @@ static Node *makeRecursiveViewSelect(char *relname, List *aliases, Node *query);
%nonassoc UNBOUNDED NESTED /* ideally would have same precedence as IDENT */
%nonassoc IDENT PARTITION RANGE ROWS GROUPS PRECEDING FOLLOWING CUBE ROLLUP
SET KEYS OBJECT_P SCALAR VALUE_P WITH WITHOUT PATH
+ MEASURES AFTER INITIAL SEEK PATTERN_P
%left Op OPERATOR /* multi-character ops and user-defined operators */
%left '+' '-'
%left '*' '/' '%'
@@ -16279,7 +16295,8 @@ over_clause: OVER window_specification
;
window_specification: '(' opt_existing_window_name opt_partition_clause
- opt_sort_clause opt_frame_clause ')'
+ opt_sort_clause opt_row_pattern_measures opt_frame_clause
+ opt_row_pattern_common_syntax ')'
{
WindowDef *n = makeNode(WindowDef);
@@ -16287,10 +16304,12 @@ window_specification: '(' opt_existing_window_name opt_partition_clause
n->refname = $2;
n->partitionClause = $3;
n->orderClause = $4;
+ n->rowPatternMeasures = $5;
/* copy relevant fields of opt_frame_clause */
- n->frameOptions = $5->frameOptions;
- n->startOffset = $5->startOffset;
- n->endOffset = $5->endOffset;
+ n->frameOptions = $6->frameOptions;
+ n->startOffset = $6->startOffset;
+ n->endOffset = $6->endOffset;
+ n->rpCommonSyntax = (RPCommonSyntax *)$7;
n->location = @1;
$$ = n;
}
@@ -16314,6 +16333,31 @@ opt_partition_clause: PARTITION BY expr_list { $$ = $3; }
| /*EMPTY*/ { $$ = NIL; }
;
+/*
+ * ROW PATTERN_P MEASURES
+ */
+opt_row_pattern_measures: MEASURES row_pattern_measure_list { $$ = $2; }
+ | /*EMPTY*/ { $$ = NIL; }
+ ;
+
+row_pattern_measure_list:
+ row_pattern_measure_item
+ { $$ = list_make1($1); }
+ | row_pattern_measure_list ',' row_pattern_measure_item
+ { $$ = lappend($1, $3); }
+ ;
+
+row_pattern_measure_item:
+ a_expr AS ColLabel
+ {
+ $$ = makeNode(ResTarget);
+ $$->name = $3;
+ $$->indirection = NIL;
+ $$->val = (Node *) $1;
+ $$->location = @1;
+ }
+ ;
+
/*
* For frame clauses, we return a WindowDef, but only some fields are used:
* frameOptions, startOffset, and endOffset.
@@ -16473,6 +16517,143 @@ opt_window_exclusion_clause:
| /*EMPTY*/ { $$ = 0; }
;
+opt_row_pattern_common_syntax:
+opt_row_pattern_skip_to opt_row_pattern_initial_or_seek
+ PATTERN_P '(' row_pattern ')'
+ opt_row_pattern_subset_clause
+ DEFINE row_pattern_definition_list
+ {
+ RPCommonSyntax *n = makeNode(RPCommonSyntax);
+ n->rpSkipTo = ((RPCommonSyntax *)$1)->rpSkipTo;
+ n->rpSkipVariable = ((RPCommonSyntax *)$1)->rpSkipVariable;
+ n->initial = $2;
+ n->rpPatterns = $5;
+ n->rpSubsetClause = $7;
+ n->rpDefs = $9;
+ $$ = (Node *) n;
+ }
+ | /*EMPTY*/ { $$ = NULL; }
+ ;
+
+opt_row_pattern_skip_to:
+ AFTER MATCH SKIP TO NEXT ROW
+ {
+ RPCommonSyntax *n = makeNode(RPCommonSyntax);
+ n->rpSkipTo = ST_NEXT_ROW;
+ n->rpSkipVariable = NULL;
+ $$ = (Node *) n;
+ }
+ | AFTER MATCH SKIP PAST LAST_P ROW
+ {
+ RPCommonSyntax *n = makeNode(RPCommonSyntax);
+ n->rpSkipTo = ST_PAST_LAST_ROW;
+ n->rpSkipVariable = NULL;
+ $$ = (Node *) n;
+ }
+ | AFTER MATCH SKIP TO first_or_last ColId
+ {
+ RPCommonSyntax *n = makeNode(RPCommonSyntax);
+ n->rpSkipTo = $5? ST_FIRST_VARIABLE : ST_LAST_VARIABLE;
+ n->rpSkipVariable = $6;
+ $$ = (Node *) n;
+ }
+/*
+ | AFTER MATCH SKIP TO LAST_P ColId %prec LAST_P
+ {
+ RPCommonSyntax *n = makeNode(RPCommonSyntax);
+ n->rpSkipTo = ST_LAST_VARIABLE;
+ n->rpSkipVariable = $6;
+ $$ = n;
+ }
+ | AFTER MATCH SKIP TO ColId
+ {
+ RPCommonSyntax *n = makeNode(RPCommonSyntax);
+ n->rpSkipTo = ST_VARIABLE;
+ n->rpSkipVariable = $5;
+ $$ = n;
+ }
+*/
+ | /*EMPTY*/
+ {
+ RPCommonSyntax *n = makeNode(RPCommonSyntax);
+ /* temporary set default to ST_NEXT_ROW */
+ n->rpSkipTo = ST_PAST_LAST_ROW;
+ n->rpSkipVariable = NULL;
+ $$ = (Node *) n;
+ }
+ ;
+
+first_or_last:
+ FIRST_P { $$ = true; }
+ | LAST_P { $$ = false; }
+ ;
+
+opt_row_pattern_initial_or_seek:
+ INITIAL { $$ = true; }
+ | SEEK
+ {
+ ereport(ERROR,
+ (errcode(ERRCODE_SYNTAX_ERROR),
+ errmsg("SEEK is not supported"),
+ errhint("Use INITIAL."),
+ parser_errposition(@1)));
+ }
+ | /*EMPTY*/ { $$ = true; }
+ ;
+
+row_pattern:
+ row_pattern_term { $$ = list_make1($1); }
+ | row_pattern row_pattern_term { $$ = lappend($1, $2); }
+ ;
+
+row_pattern_term:
+ ColId { $$ = (Node *) makeSimpleA_Expr(AEXPR_OP, "", (Node *)makeString($1), NULL, @1); }
+ | ColId '*' { $$ = (Node *) makeSimpleA_Expr(AEXPR_OP, "*", (Node *)makeString($1), NULL, @1); }
+ | ColId '+' { $$ = (Node *) makeSimpleA_Expr(AEXPR_OP, "+", (Node *)makeString($1), NULL, @1); }
+ | ColId '?' { $$ = (Node *) makeSimpleA_Expr(AEXPR_OP, "?", (Node *)makeString($1), NULL, @1); }
+ ;
+
+opt_row_pattern_subset_clause:
+ SUBSET row_pattern_subset_list { $$ = $2; }
+ | /*EMPTY*/ { $$ = NIL; }
+ ;
+
+row_pattern_subset_list:
+ row_pattern_subset_item { $$ = list_make1($1); }
+ | row_pattern_subset_list ',' row_pattern_subset_item { $$ = lappend($1, $3); }
+ | /*EMPTY*/ { $$ = NIL; }
+ ;
+
+row_pattern_subset_item: ColId '=' '(' row_pattern_subset_rhs ')'
+ {
+ RPSubsetItem *n = makeNode(RPSubsetItem);
+ n->name = $1;
+ n->rhsVariable = $4;
+ $$ = (Node *) n;
+ }
+ ;
+
+row_pattern_subset_rhs:
+ ColId { $$ = list_make1(makeStringConst($1, @1)); }
+ | row_pattern_subset_rhs ',' ColId { $$ = lappend($1, makeStringConst($3, @1)); }
+ | /*EMPTY*/ { $$ = NIL; }
+ ;
+
+row_pattern_definition_list:
+ row_pattern_definition { $$ = list_make1($1); }
+ | row_pattern_definition_list ',' row_pattern_definition { $$ = lappend($1, $3); }
+ ;
+
+row_pattern_definition:
+ ColId AS a_expr
+ {
+ $$ = makeNode(ResTarget);
+ $$->name = $1;
+ $$->indirection = NIL;
+ $$->val = (Node *) $3;
+ $$->location = @1;
+ }
+ ;
/*
* Supporting nonterminals for expressions.
@@ -17683,6 +17864,7 @@ unreserved_keyword:
| INDEXES
| INHERIT
| INHERITS
+ | INITIAL
| INLINE_P
| INPUT_P
| INSENSITIVE
@@ -17711,6 +17893,7 @@ unreserved_keyword:
| MATCHED
| MATERIALIZED
| MAXVALUE
+ | MEASURES
| MERGE
| METHOD
| MINUTE_P
@@ -17756,8 +17939,11 @@ unreserved_keyword:
| PARTITIONS
| PASSING
| PASSWORD
+ | PAST
| PATH
+ | PATTERN_P
| PERIOD
+ | PERMUTE
| PLAN
| PLANS
| POLICY
@@ -17810,6 +17996,7 @@ unreserved_keyword:
| SEARCH
| SECOND_P
| SECURITY
+ | SEEK
| SEQUENCE
| SEQUENCES
| SERIALIZABLE
@@ -17838,6 +18025,7 @@ unreserved_keyword:
| STRING_P
| STRIP_P
| SUBSCRIPTION
+ | SUBSET
| SUPPORT
| SYSID
| SYSTEM_P
@@ -18032,6 +18220,7 @@ reserved_keyword:
| CURRENT_USER
| DEFAULT
| DEFERRABLE
+ | DEFINE
| DESC
| DISTINCT
| DO
@@ -18195,6 +18384,7 @@ bare_label_keyword:
| DEFAULTS
| DEFERRABLE
| DEFERRED
+ | DEFINE
| DEFINER
| DELETE_P
| DELIMITER
@@ -18272,6 +18462,7 @@ bare_label_keyword:
| INDEXES
| INHERIT
| INHERITS
+ | INITIAL
| INITIALLY
| INLINE_P
| INNER_P
@@ -18326,6 +18517,7 @@ bare_label_keyword:
| MATCHED
| MATERIALIZED
| MAXVALUE
+ | MEASURES
| MERGE
| MERGE_ACTION
| METHOD
@@ -18383,8 +18575,11 @@ bare_label_keyword:
| PARTITIONS
| PASSING
| PASSWORD
+ | PAST
| PATH
+ | PATTERN_P
| PERIOD
+ | PERMUTE
| PLACING
| PLAN
| PLANS
@@ -18443,6 +18638,7 @@ bare_label_keyword:
| SCROLL
| SEARCH
| SECURITY
+ | SEEK
| SELECT
| SEQUENCE
| SEQUENCES
@@ -18477,6 +18673,7 @@ bare_label_keyword:
| STRING_P
| STRIP_P
| SUBSCRIPTION
+ | SUBSET
| SUBSTRING
| SUPPORT
| SYMMETRIC
diff --git a/src/include/nodes/parsenodes.h b/src/include/nodes/parsenodes.h
index f763f790b1..aef5fbf458 100644
--- a/src/include/nodes/parsenodes.h
+++ b/src/include/nodes/parsenodes.h
@@ -550,6 +550,48 @@ typedef struct SortBy
ParseLoc location; /* operator location, or -1 if none/unknown */
} SortBy;
+/*
+ * AFTER MATCH row pattern skip to types in row pattern common syntax
+ */
+typedef enum RPSkipTo
+{
+ ST_NONE, /* AFTER MATCH omitted */
+ ST_NEXT_ROW, /* SKIP TO NEXT ROW */
+ ST_PAST_LAST_ROW, /* SKIP TO PAST LAST ROW */
+ ST_FIRST_VARIABLE, /* SKIP TO FIRST variable name */
+ ST_LAST_VARIABLE, /* SKIP TO LAST variable name */
+ ST_VARIABLE /* SKIP TO variable name */
+} RPSkipTo;
+
+/*
+ * Row Pattern SUBSET clause item
+ */
+typedef struct RPSubsetItem
+{
+ NodeTag type;
+ char *name; /* Row Pattern SUBSET clause variable name */
+ List *rhsVariable; /* Row Pattern SUBSET rhs variables (list of
+ * char *string) */
+} RPSubsetItem;
+
+/*
+ * RowPatternCommonSyntax - raw representation of row pattern common syntax
+ *
+ */
+typedef struct RPCommonSyntax
+{
+ NodeTag type;
+ RPSkipTo rpSkipTo; /* Row Pattern AFTER MATCH SKIP type */
+ char *rpSkipVariable; /* Row Pattern Skip To variable name, if any */
+ bool initial; /* true if <row pattern initial or seek> is
+ * initial */
+ List *rpPatterns; /* PATTERN variables (list of A_Expr) */
+ List *rpSubsetClause; /* row pattern subset clause (list of
+ * RPSubsetItem), if any */
+ List *rpDefs; /* row pattern definitions clause (list of
+ * ResTarget) */
+} RPCommonSyntax;
+
/*
* WindowDef - raw representation of WINDOW and OVER clauses
*
@@ -565,6 +607,9 @@ typedef struct WindowDef
char *refname; /* referenced window name, if any */
List *partitionClause; /* PARTITION BY expression list */
List *orderClause; /* ORDER BY (list of SortBy) */
+ List *rowPatternMeasures; /* row pattern measures (list of
+ * ResTarget) */
+ RPCommonSyntax *rpCommonSyntax; /* row pattern common syntax */
int frameOptions; /* frame_clause options, see below */
Node *startOffset; /* expression for starting bound, if any */
Node *endOffset; /* expression for ending bound, if any */
@@ -1533,6 +1578,11 @@ typedef struct GroupingSet
* the orderClause might or might not be copied (see copiedOrder); the framing
* options are never copied, per spec.
*
+ * "defineClause" is Row Pattern Recognition DEFINE clause (list of
+ * TargetEntry). TargetEntry.resname represents row pattern definition
+ * variable name. "patternVariable" and "patternRegexp" represents PATTERN
+ * clause.
+ *
* The information relevant for the query jumbling is the partition clause
* type and its bounds.
*/
@@ -1564,6 +1614,23 @@ typedef struct WindowClause
Index winref; /* ID referenced by window functions */
/* did we copy orderClause from refname? */
bool copiedOrder pg_node_attr(query_jumble_ignore);
+ /* Row Pattern AFTER MACH SKIP clause */
+ RPSkipTo rpSkipTo; /* Row Pattern Skip To type */
+ char *rpSkipVariable; /* Row Pattern Skip To variable */
+ bool initial; /* true if <row pattern initial or seek> is
+ * initial */
+ /* Row Pattern DEFINE clause (list of TargetEntry) */
+ List *defineClause;
+ /* Row Pattern DEFINE variable initial names (list of String) */
+ List *defineInitial;
+ /* Row Pattern PATTERN variable name (list of String) */
+ List *patternVariable;
+
+ /*
+ * Row Pattern PATTERN regular expression quantifier ('+' or ''. list of
+ * String)
+ */
+ List *patternRegexp;
} WindowClause;
/*
diff --git a/src/include/parser/kwlist.h b/src/include/parser/kwlist.h
index f9a4afd472..df49492629 100644
--- a/src/include/parser/kwlist.h
+++ b/src/include/parser/kwlist.h
@@ -129,6 +129,7 @@ PG_KEYWORD("default", DEFAULT, RESERVED_KEYWORD, BARE_LABEL)
PG_KEYWORD("defaults", DEFAULTS, UNRESERVED_KEYWORD, BARE_LABEL)
PG_KEYWORD("deferrable", DEFERRABLE, RESERVED_KEYWORD, BARE_LABEL)
PG_KEYWORD("deferred", DEFERRED, UNRESERVED_KEYWORD, BARE_LABEL)
+PG_KEYWORD("define", DEFINE, RESERVED_KEYWORD, BARE_LABEL)
PG_KEYWORD("definer", DEFINER, UNRESERVED_KEYWORD, BARE_LABEL)
PG_KEYWORD("delete", DELETE_P, UNRESERVED_KEYWORD, BARE_LABEL)
PG_KEYWORD("delimiter", DELIMITER, UNRESERVED_KEYWORD, BARE_LABEL)
@@ -215,6 +216,7 @@ PG_KEYWORD("index", INDEX, UNRESERVED_KEYWORD, BARE_LABEL)
PG_KEYWORD("indexes", INDEXES, UNRESERVED_KEYWORD, BARE_LABEL)
PG_KEYWORD("inherit", INHERIT, UNRESERVED_KEYWORD, BARE_LABEL)
PG_KEYWORD("inherits", INHERITS, UNRESERVED_KEYWORD, BARE_LABEL)
+PG_KEYWORD("initial", INITIAL, UNRESERVED_KEYWORD, BARE_LABEL)
PG_KEYWORD("initially", INITIALLY, RESERVED_KEYWORD, BARE_LABEL)
PG_KEYWORD("inline", INLINE_P, UNRESERVED_KEYWORD, BARE_LABEL)
PG_KEYWORD("inner", INNER_P, TYPE_FUNC_NAME_KEYWORD, BARE_LABEL)
@@ -273,6 +275,7 @@ PG_KEYWORD("match", MATCH, UNRESERVED_KEYWORD, BARE_LABEL)
PG_KEYWORD("matched", MATCHED, UNRESERVED_KEYWORD, BARE_LABEL)
PG_KEYWORD("materialized", MATERIALIZED, UNRESERVED_KEYWORD, BARE_LABEL)
PG_KEYWORD("maxvalue", MAXVALUE, UNRESERVED_KEYWORD, BARE_LABEL)
+PG_KEYWORD("measures", MEASURES, UNRESERVED_KEYWORD, BARE_LABEL)
PG_KEYWORD("merge", MERGE, UNRESERVED_KEYWORD, BARE_LABEL)
PG_KEYWORD("merge_action", MERGE_ACTION, COL_NAME_KEYWORD, BARE_LABEL)
PG_KEYWORD("method", METHOD, UNRESERVED_KEYWORD, BARE_LABEL)
@@ -338,8 +341,11 @@ PG_KEYWORD("partition", PARTITION, UNRESERVED_KEYWORD, BARE_LABEL)
PG_KEYWORD("partitions", PARTITIONS, UNRESERVED_KEYWORD, BARE_LABEL)
PG_KEYWORD("passing", PASSING, UNRESERVED_KEYWORD, BARE_LABEL)
PG_KEYWORD("password", PASSWORD, UNRESERVED_KEYWORD, BARE_LABEL)
+PG_KEYWORD("past", PAST, UNRESERVED_KEYWORD, BARE_LABEL)
PG_KEYWORD("path", PATH, UNRESERVED_KEYWORD, BARE_LABEL)
+PG_KEYWORD("pattern", PATTERN_P, UNRESERVED_KEYWORD, BARE_LABEL)
PG_KEYWORD("period", PERIOD, UNRESERVED_KEYWORD, BARE_LABEL)
+PG_KEYWORD("permute", PERMUTE, UNRESERVED_KEYWORD, BARE_LABEL)
PG_KEYWORD("placing", PLACING, RESERVED_KEYWORD, BARE_LABEL)
PG_KEYWORD("plan", PLAN, UNRESERVED_KEYWORD, BARE_LABEL)
PG_KEYWORD("plans", PLANS, UNRESERVED_KEYWORD, BARE_LABEL)
@@ -401,6 +407,7 @@ PG_KEYWORD("scroll", SCROLL, UNRESERVED_KEYWORD, BARE_LABEL)
PG_KEYWORD("search", SEARCH, UNRESERVED_KEYWORD, BARE_LABEL)
PG_KEYWORD("second", SECOND_P, UNRESERVED_KEYWORD, AS_LABEL)
PG_KEYWORD("security", SECURITY, UNRESERVED_KEYWORD, BARE_LABEL)
+PG_KEYWORD("seek", SEEK, UNRESERVED_KEYWORD, BARE_LABEL)
PG_KEYWORD("select", SELECT, RESERVED_KEYWORD, BARE_LABEL)
PG_KEYWORD("sequence", SEQUENCE, UNRESERVED_KEYWORD, BARE_LABEL)
PG_KEYWORD("sequences", SEQUENCES, UNRESERVED_KEYWORD, BARE_LABEL)
@@ -435,6 +442,7 @@ PG_KEYWORD("strict", STRICT_P, UNRESERVED_KEYWORD, BARE_LABEL)
PG_KEYWORD("string", STRING_P, UNRESERVED_KEYWORD, BARE_LABEL)
PG_KEYWORD("strip", STRIP_P, UNRESERVED_KEYWORD, BARE_LABEL)
PG_KEYWORD("subscription", SUBSCRIPTION, UNRESERVED_KEYWORD, BARE_LABEL)
+PG_KEYWORD("subset", SUBSET, UNRESERVED_KEYWORD, BARE_LABEL)
PG_KEYWORD("substring", SUBSTRING, COL_NAME_KEYWORD, BARE_LABEL)
PG_KEYWORD("support", SUPPORT, UNRESERVED_KEYWORD, BARE_LABEL)
PG_KEYWORD("symmetric", SYMMETRIC, RESERVED_KEYWORD, BARE_LABEL)
diff --git a/src/include/parser/parse_node.h b/src/include/parser/parse_node.h
index 5b781d87a9..66935afff8 100644
--- a/src/include/parser/parse_node.h
+++ b/src/include/parser/parse_node.h
@@ -51,6 +51,7 @@ typedef enum ParseExprKind
EXPR_KIND_WINDOW_FRAME_RANGE, /* window frame clause with RANGE */
EXPR_KIND_WINDOW_FRAME_ROWS, /* window frame clause with ROWS */
EXPR_KIND_WINDOW_FRAME_GROUPS, /* window frame clause with GROUPS */
+ EXPR_KIND_RPR_DEFINE, /* DEFINE */
EXPR_KIND_SELECT_TARGET, /* SELECT target list item */
EXPR_KIND_INSERT_TARGET, /* INSERT target list item */
EXPR_KIND_UPDATE_SOURCE, /* UPDATE assignment source item */
--
2.25.1
----Next_Part(Fri_Apr_12_16_09_08_2024_262)--
Content-Type: Text/X-Patch; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="v16-0002-Row-pattern-recognition-patch-parse-analysis.patch"
^ permalink raw reply [nested|flat] 33+ messages in thread
end of thread, other threads:[~2024-04-12 06:49 UTC | newest]
Thread overview: 33+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2019-01-20 08:11 [PATCH v18 15/18] tableam: bitmap heap scan. Andres Freund <[email protected]>
2024-03-11 21:12 Re: Reports on obsolete Postgres versions Nathan Bossart <[email protected]>
2024-03-11 21:17 ` Re: Reports on obsolete Postgres versions Bruce Momjian <[email protected]>
2024-03-12 01:37 ` Re: Reports on obsolete Postgres versions Nathan Bossart <[email protected]>
2024-03-12 10:00 ` Re: Reports on obsolete Postgres versions Daniel Gustafsson <[email protected]>
2024-03-12 10:12 ` Re: Reports on obsolete Postgres versions Michael Banck <[email protected]>
2024-03-12 10:56 ` Re: Reports on obsolete Postgres versions Daniel Gustafsson <[email protected]>
2024-03-13 16:21 ` Re: Reports on obsolete Postgres versions Jeremy Schneider <[email protected]>
2024-03-13 17:12 ` Re: Reports on obsolete Postgres versions Bruce Momjian <[email protected]>
2024-03-13 18:04 ` Re: Reports on obsolete Postgres versions Robert Treat <[email protected]>
2024-03-13 18:21 ` Re: Reports on obsolete Postgres versions Tom Lane <[email protected]>
2024-03-13 18:29 ` Re: Reports on obsolete Postgres versions Jeremy Schneider <[email protected]>
2024-03-13 18:39 ` Re: Reports on obsolete Postgres versions Tom Lane <[email protected]>
2024-03-13 18:47 ` Re: Reports on obsolete Postgres versions Jeremy Schneider <[email protected]>
2024-04-02 09:31 ` Re: Reports on obsolete Postgres versions Magnus Hagander <[email protected]>
2024-03-13 18:52 ` Re: Reports on obsolete Postgres versions Nathan Bossart <[email protected]>
2024-04-01 22:56 ` Re: Reports on obsolete Postgres versions Bruce Momjian <[email protected]>
2024-04-02 07:24 ` Re: Reports on obsolete Postgres versions Daniel Gustafsson <[email protected]>
2024-04-02 09:34 ` Re: Reports on obsolete Postgres versions Magnus Hagander <[email protected]>
2024-04-02 20:46 ` Re: Reports on obsolete Postgres versions Bruce Momjian <[email protected]>
2024-04-02 20:48 ` Re: Reports on obsolete Postgres versions Daniel Gustafsson <[email protected]>
2024-04-04 01:01 ` Re: Reports on obsolete Postgres versions David G. Johnston <[email protected]>
2024-04-04 18:23 ` Re: Reports on obsolete Postgres versions Bruce Momjian <[email protected]>
2024-04-04 19:27 ` Re: Reports on obsolete Postgres versions David G. Johnston <[email protected]>
2024-03-14 15:48 ` Re: Reports on obsolete Postgres versions Peter Eisentraut <[email protected]>
2024-03-15 10:17 ` Re: Reports on obsolete Postgres versions Daniel Gustafsson <[email protected]>
2024-03-15 16:14 ` Re: Reports on obsolete Postgres versions Michael Banck <[email protected]>
2024-03-15 16:48 ` Re: Reports on obsolete Postgres versions Jeremy Schneider <[email protected]>
2024-03-13 19:04 ` Re: Reports on obsolete Postgres versions Laurenz Albe <[email protected]>
2024-03-14 14:15 ` Re: Reports on obsolete Postgres versions Robert Haas <[email protected]>
2024-03-15 02:46 ` Re: Reports on obsolete Postgres versions Bruce Momjian <[email protected]>
2024-03-15 02:50 ` Re: Reports on obsolete Postgres versions Bruce Momjian <[email protected]>
2024-04-12 06:49 [PATCH v16 1/8] Row pattern recognition patch for raw parser. Tatsuo Ishii <[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