pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  

help / color / mirror / Atom feed

[PATCH v6 04/14] bufmgr: Change BufferDesc.state to be a 64bit atomic
129+ messages / 32 participants
[nested] [flat]

* [PATCH v6 04/14] bufmgr: Change BufferDesc.state to be a 64bit atomic
@ 2025-11-06 00:22  Andres Freund <andres@anarazel.de>
  0 siblings, 0 replies; 129+ messages in thread

From: Andres Freund @ 2025-11-06 00:22 UTC (permalink / raw)

This is motivated by wanting to merge buffer content locks into
BufferDesc.state in a future commit, rather than having a separate lwlock (see
commit c75ebc657ff more details). As this change is rather mechanical, it
seems to make sense to split it out into a separate commit, for easier review.

Discussion: https://postgr.es/m/fvfmkr5kk4nyex56ejgxj3uzi63isfxovp2biecb4bspbjrze7@az2pljabhnff
---
 src/include/storage/buf_internals.h           |  88 ++++++----
 src/backend/storage/buffer/buf_init.c         |   2 +-
 src/backend/storage/buffer/bufmgr.c           | 158 +++++++++---------
 src/backend/storage/buffer/freelist.c         |  24 +--
 src/backend/storage/buffer/localbuf.c         |  72 ++++----
 contrib/pg_buffercache/pg_buffercache_pages.c |   8 +-
 src/test/modules/test_aio/test_aio.c          |  12 +-
 7 files changed, 192 insertions(+), 172 deletions(-)

diff --git a/src/include/storage/buf_internals.h b/src/include/storage/buf_internals.h
index 5400c56a965..28519ad2813 100644
--- a/src/include/storage/buf_internals.h
+++ b/src/include/storage/buf_internals.h
@@ -30,7 +30,7 @@
 #include "utils/resowner.h"
 
 /*
- * Buffer state is a single 32-bit variable where following data is combined.
+ * Buffer state is a single 64-bit variable where following data is combined.
  *
  * - 18 bits refcount
  * - 4 bits usage count
@@ -39,6 +39,9 @@
  * Combining these values allows to perform some operations without locking
  * the buffer header, by modifying them together with a CAS loop.
  *
+ * NB: A future commit will use a significant portion of the remaining bits to
+ * implement buffer locking as part of the state variable.
+ *
  * The definition of buffer state components is below.
  */
 #define BUF_REFCOUNT_BITS 18
@@ -49,15 +52,21 @@ StaticAssertDecl(BUF_REFCOUNT_BITS + BUF_USAGECOUNT_BITS + BUF_FLAG_BITS == 32,
 				 "parts of buffer state space need to equal 32");
 
 #define BUF_REFCOUNT_ONE 1
-#define BUF_REFCOUNT_MASK ((1U << BUF_REFCOUNT_BITS) - 1)
-#define BUF_USAGECOUNT_MASK (((1U << BUF_USAGECOUNT_BITS) - 1) << (BUF_REFCOUNT_BITS))
-#define BUF_USAGECOUNT_ONE (1U << BUF_REFCOUNT_BITS)
+#define BUF_REFCOUNT_MASK \
+	((UINT64CONST(1) << BUF_REFCOUNT_BITS) - 1)
+#define BUF_USAGECOUNT_MASK \
+	(((UINT64CONST(1) << BUF_USAGECOUNT_BITS) - 1) << (BUF_REFCOUNT_BITS))
+#define BUF_USAGECOUNT_ONE \
+	(UINT64CONST(1) << BUF_REFCOUNT_BITS)
 #define BUF_USAGECOUNT_SHIFT BUF_REFCOUNT_BITS
-#define BUF_FLAG_MASK (((1U << BUF_FLAG_BITS) - 1) << (BUF_REFCOUNT_BITS + BUF_USAGECOUNT_BITS))
+#define BUF_FLAG_MASK \
+	(((UINT64CONST(1) << BUF_FLAG_BITS) - 1) << (BUF_REFCOUNT_BITS + BUF_USAGECOUNT_BITS))
 
 /* Get refcount and usagecount from buffer state */
-#define BUF_STATE_GET_REFCOUNT(state) ((state) & BUF_REFCOUNT_MASK)
-#define BUF_STATE_GET_USAGECOUNT(state) (((state) & BUF_USAGECOUNT_MASK) >> BUF_USAGECOUNT_SHIFT)
+#define BUF_STATE_GET_REFCOUNT(state) \
+	((uint32)((state) & BUF_REFCOUNT_MASK))
+#define BUF_STATE_GET_USAGECOUNT(state) \
+	((uint32)(((state) & BUF_USAGECOUNT_MASK) >> BUF_USAGECOUNT_SHIFT))
 
 /*
  * Flags for buffer descriptors
@@ -65,17 +74,28 @@ StaticAssertDecl(BUF_REFCOUNT_BITS + BUF_USAGECOUNT_BITS + BUF_FLAG_BITS == 32,
  * Note: BM_TAG_VALID essentially means that there is a buffer hashtable
  * entry associated with the buffer's tag.
  */
-#define BM_LOCKED				(1U << 22)	/* buffer header is locked */
-#define BM_DIRTY				(1U << 23)	/* data needs writing */
-#define BM_VALID				(1U << 24)	/* data is valid */
-#define BM_TAG_VALID			(1U << 25)	/* tag is assigned */
-#define BM_IO_IN_PROGRESS		(1U << 26)	/* read or write in progress */
-#define BM_IO_ERROR				(1U << 27)	/* previous I/O failed */
-#define BM_JUST_DIRTIED			(1U << 28)	/* dirtied since write started */
-#define BM_PIN_COUNT_WAITER		(1U << 29)	/* have waiter for sole pin */
-#define BM_CHECKPOINT_NEEDED	(1U << 30)	/* must write for checkpoint */
-#define BM_PERMANENT			(1U << 31)	/* permanent buffer (not unlogged,
-											 * or init fork) */
+
+/* buffer header is locked */
+#define BM_LOCKED				(UINT64CONST(1) << 22)
+/* data needs writing */
+#define BM_DIRTY				(UINT64CONST(1) << 23)
+/* data is valid */
+#define BM_VALID				(UINT64CONST(1) << 24)
+/* tag is assigned */
+#define BM_TAG_VALID			(UINT64CONST(1) << 25)
+/* read or write in progress */
+#define BM_IO_IN_PROGRESS		(UINT64CONST(1) << 26)
+/* previous I/O failed */
+#define BM_IO_ERROR				(UINT64CONST(1) << 27)
+/* dirtied since write started */
+#define BM_JUST_DIRTIED			(UINT64CONST(1) << 28)
+/* have waiter for sole pin */
+#define BM_PIN_COUNT_WAITER		(UINT64CONST(1) << 29)
+/* must write for checkpoint */
+#define BM_CHECKPOINT_NEEDED	(UINT64CONST(1) << 30)
+/* permanent buffer (not unlogged, or init fork) */
+#define BM_PERMANENT			(UINT64CONST(1) << 31)
+
 /*
  * The maximum allowed value of usage_count represents a tradeoff between
  * accuracy and speed of the clock-sweep buffer management algorithm.  A
@@ -86,7 +106,7 @@ StaticAssertDecl(BUF_REFCOUNT_BITS + BUF_USAGECOUNT_BITS + BUF_FLAG_BITS == 32,
  */
 #define BM_MAX_USAGE_COUNT	5
 
-StaticAssertDecl(BM_MAX_USAGE_COUNT < (1 << BUF_USAGECOUNT_BITS),
+StaticAssertDecl(BM_MAX_USAGE_COUNT < (UINT64CONST(1) << BUF_USAGECOUNT_BITS),
 				 "BM_MAX_USAGE_COUNT doesn't fit in BUF_USAGECOUNT_BITS bits");
 StaticAssertDecl(MAX_BACKENDS_BITS <= BUF_REFCOUNT_BITS,
 				 "MAX_BACKENDS_BITS needs to be <= BUF_REFCOUNT_BITS");
@@ -251,8 +271,8 @@ BufMappingPartitionLockByIndex(uint32 index)
  * We use this same struct for local buffer headers, but the locks are not
  * used and not all of the flag bits are useful either. To avoid unnecessary
  * overhead, manipulations of the state field should be done without actual
- * atomic operations (i.e. only pg_atomic_read_u32() and
- * pg_atomic_unlocked_write_u32()).
+ * atomic operations (i.e. only pg_atomic_read_u64() and
+ * pg_atomic_unlocked_write_u64()).
  *
  * Be careful to avoid increasing the size of the struct when adding or
  * reordering members.  Keeping it below 64 bytes (the most common CPU
@@ -280,7 +300,7 @@ typedef struct BufferDesc
 	 * State of the buffer, containing flags, refcount and usagecount. See
 	 * BUF_* and BM_* defines at the top of this file.
 	 */
-	pg_atomic_uint32 state;
+	pg_atomic_uint64 state;
 
 	/*
 	 * Backend of pin-count waiter. The buffer header spinlock needs to be
@@ -386,7 +406,7 @@ BufferDescriptorGetContentLock(const BufferDesc *bdesc)
  * Functions for acquiring/releasing a shared buffer header's spinlock.  Do
  * not apply these to local buffers!
  */
-extern uint32 LockBufHdr(BufferDesc *desc);
+extern uint64 LockBufHdr(BufferDesc *desc);
 
 /*
  * Unlock the buffer header.
@@ -397,9 +417,9 @@ extern uint32 LockBufHdr(BufferDesc *desc);
 static inline void
 UnlockBufHdr(BufferDesc *desc)
 {
-	Assert(pg_atomic_read_u32(&desc->state) & BM_LOCKED);
+	Assert(pg_atomic_read_u64(&desc->state) & BM_LOCKED);
 
-	pg_atomic_fetch_sub_u32(&desc->state, BM_LOCKED);
+	pg_atomic_fetch_sub_u64(&desc->state, BM_LOCKED);
 }
 
 /*
@@ -410,14 +430,14 @@ UnlockBufHdr(BufferDesc *desc)
  * Note that this approach would not work for usagecount, since we need to cap
  * the usagecount at BM_MAX_USAGE_COUNT.
  */
-static inline uint32
-UnlockBufHdrExt(BufferDesc *desc, uint32 old_buf_state,
-				uint32 set_bits, uint32 unset_bits,
+static inline uint64
+UnlockBufHdrExt(BufferDesc *desc, uint64 old_buf_state,
+				uint64 set_bits, uint64 unset_bits,
 				int refcount_change)
 {
 	for (;;)
 	{
-		uint32		buf_state = old_buf_state;
+		uint64		buf_state = old_buf_state;
 
 		Assert(buf_state & BM_LOCKED);
 
@@ -428,7 +448,7 @@ UnlockBufHdrExt(BufferDesc *desc, uint32 old_buf_state,
 		if (refcount_change != 0)
 			buf_state += BUF_REFCOUNT_ONE * refcount_change;
 
-		if (pg_atomic_compare_exchange_u32(&desc->state, &old_buf_state,
+		if (pg_atomic_compare_exchange_u64(&desc->state, &old_buf_state,
 										   buf_state))
 		{
 			return old_buf_state;
@@ -436,7 +456,7 @@ UnlockBufHdrExt(BufferDesc *desc, uint32 old_buf_state,
 	}
 }
 
-extern uint32 WaitBufHdrUnlocked(BufferDesc *buf);
+extern uint64 WaitBufHdrUnlocked(BufferDesc *buf);
 
 /* in bufmgr.c */
 
@@ -496,14 +516,14 @@ extern void TrackNewBufferPin(Buffer buf);
 
 /* solely to make it easier to write tests */
 extern bool StartBufferIO(BufferDesc *buf, bool forInput, bool nowait);
-extern void TerminateBufferIO(BufferDesc *buf, bool clear_dirty, uint32 set_flag_bits,
+extern void TerminateBufferIO(BufferDesc *buf, bool clear_dirty, uint64 set_flag_bits,
 							  bool forget_owner, bool release_aio);
 
 
 /* freelist.c */
 extern IOContext IOContextForStrategy(BufferAccessStrategy strategy);
 extern BufferDesc *StrategyGetBuffer(BufferAccessStrategy strategy,
-									 uint32 *buf_state, bool *from_ring);
+									 uint64 *buf_state, bool *from_ring);
 extern bool StrategyRejectBuffer(BufferAccessStrategy strategy,
 								 BufferDesc *buf, bool from_ring);
 
@@ -539,7 +559,7 @@ extern BlockNumber ExtendBufferedRelLocal(BufferManagerRelation bmr,
 										  uint32 *extended_by);
 extern void MarkLocalBufferDirty(Buffer buffer);
 extern void TerminateLocalBufferIO(BufferDesc *bufHdr, bool clear_dirty,
-								   uint32 set_flag_bits, bool release_aio);
+								   uint64 set_flag_bits, bool release_aio);
 extern bool StartLocalBufferIO(BufferDesc *bufHdr, bool forInput, bool nowait);
 extern void FlushLocalBuffer(BufferDesc *bufHdr, SMgrRelation reln);
 extern void InvalidateLocalBuffer(BufferDesc *bufHdr, bool check_unreferenced);
diff --git a/src/backend/storage/buffer/buf_init.c b/src/backend/storage/buffer/buf_init.c
index 6fd3a6bbac5..25f71191ec3 100644
--- a/src/backend/storage/buffer/buf_init.c
+++ b/src/backend/storage/buffer/buf_init.c
@@ -121,7 +121,7 @@ BufferManagerShmemInit(void)
 
 			ClearBufferTag(&buf->tag);
 
-			pg_atomic_init_u32(&buf->state, 0);
+			pg_atomic_init_u64(&buf->state, 0);
 			buf->wait_backend_pgprocno = INVALID_PROC_NUMBER;
 
 			buf->buf_id = i;
diff --git a/src/backend/storage/buffer/bufmgr.c b/src/backend/storage/buffer/bufmgr.c
index b682878b1fb..e33fa0cbfec 100644
--- a/src/backend/storage/buffer/bufmgr.c
+++ b/src/backend/storage/buffer/bufmgr.c
@@ -686,7 +686,7 @@ ReadRecentBuffer(RelFileLocator rlocator, ForkNumber forkNum, BlockNumber blockN
 {
 	BufferDesc *bufHdr;
 	BufferTag	tag;
-	uint32		buf_state;
+	uint64		buf_state;
 
 	Assert(BufferIsValid(recent_buffer));
 
@@ -699,7 +699,7 @@ ReadRecentBuffer(RelFileLocator rlocator, ForkNumber forkNum, BlockNumber blockN
 		int			b = -recent_buffer - 1;
 
 		bufHdr = GetLocalBufferDescriptor(b);
-		buf_state = pg_atomic_read_u32(&bufHdr->state);
+		buf_state = pg_atomic_read_u64(&bufHdr->state);
 
 		/* Is it still valid and holding the right tag? */
 		if ((buf_state & BM_VALID) && BufferTagsEqual(&tag, &bufHdr->tag))
@@ -1292,8 +1292,8 @@ StartReadBuffersImpl(ReadBuffersOperation *operation,
 				bufHdr = GetLocalBufferDescriptor(-buffers[i] - 1);
 			else
 				bufHdr = GetBufferDescriptor(buffers[i] - 1);
-			Assert(pg_atomic_read_u32(&bufHdr->state) & BM_TAG_VALID);
-			found = pg_atomic_read_u32(&bufHdr->state) & BM_VALID;
+			Assert(pg_atomic_read_u64(&bufHdr->state) & BM_TAG_VALID);
+			found = pg_atomic_read_u64(&bufHdr->state) & BM_VALID;
 		}
 		else
 		{
@@ -1519,10 +1519,10 @@ CheckReadBuffersOperation(ReadBuffersOperation *operation, bool is_complete)
 			GetBufferDescriptor(buffer - 1);
 
 		Assert(BufferGetBlockNumber(buffer) == operation->blocknum + i);
-		Assert(pg_atomic_read_u32(&buf_hdr->state) & BM_TAG_VALID);
+		Assert(pg_atomic_read_u64(&buf_hdr->state) & BM_TAG_VALID);
 
 		if (i < operation->nblocks_done)
-			Assert(pg_atomic_read_u32(&buf_hdr->state) & BM_VALID);
+			Assert(pg_atomic_read_u64(&buf_hdr->state) & BM_VALID);
 	}
 #endif
 }
@@ -1989,8 +1989,8 @@ BufferAlloc(SMgrRelation smgr, char relpersistence, ForkNumber forkNum,
 	int			existing_buf_id;
 	Buffer		victim_buffer;
 	BufferDesc *victim_buf_hdr;
-	uint32		victim_buf_state;
-	uint32		set_bits = 0;
+	uint64		victim_buf_state;
+	uint64		set_bits = 0;
 
 	/* Make sure we will have room to remember the buffer pin */
 	ResourceOwnerEnlarge(CurrentResourceOwner);
@@ -2157,7 +2157,7 @@ InvalidateBuffer(BufferDesc *buf)
 	uint32		oldHash;		/* hash value for oldTag */
 	LWLock	   *oldPartitionLock;	/* buffer partition lock for it */
 	uint32		oldFlags;
-	uint32		buf_state;
+	uint64		buf_state;
 
 	/* Save the original buffer tag before dropping the spinlock */
 	oldTag = buf->tag;
@@ -2248,7 +2248,7 @@ retry:
 static bool
 InvalidateVictimBuffer(BufferDesc *buf_hdr)
 {
-	uint32		buf_state;
+	uint64		buf_state;
 	uint32		hash;
 	LWLock	   *partition_lock;
 	BufferTag	tag;
@@ -2308,10 +2308,10 @@ InvalidateVictimBuffer(BufferDesc *buf_hdr)
 
 	LWLockRelease(partition_lock);
 
-	buf_state = pg_atomic_read_u32(&buf_hdr->state);
+	buf_state = pg_atomic_read_u64(&buf_hdr->state);
 	Assert(!(buf_state & (BM_DIRTY | BM_VALID | BM_TAG_VALID)));
 	Assert(BUF_STATE_GET_REFCOUNT(buf_state) > 0);
-	Assert(BUF_STATE_GET_REFCOUNT(pg_atomic_read_u32(&buf_hdr->state)) > 0);
+	Assert(BUF_STATE_GET_REFCOUNT(pg_atomic_read_u64(&buf_hdr->state)) > 0);
 
 	return true;
 }
@@ -2321,7 +2321,7 @@ GetVictimBuffer(BufferAccessStrategy strategy, IOContext io_context)
 {
 	BufferDesc *buf_hdr;
 	Buffer		buf;
-	uint32		buf_state;
+	uint64		buf_state;
 	bool		from_ring;
 
 	/*
@@ -2454,7 +2454,7 @@ again:
 
 	/* a final set of sanity checks */
 #ifdef USE_ASSERT_CHECKING
-	buf_state = pg_atomic_read_u32(&buf_hdr->state);
+	buf_state = pg_atomic_read_u64(&buf_hdr->state);
 
 	Assert(BUF_STATE_GET_REFCOUNT(buf_state) == 1);
 	Assert(!(buf_state & (BM_TAG_VALID | BM_VALID | BM_DIRTY)));
@@ -2745,13 +2745,13 @@ ExtendBufferedRelShared(BufferManagerRelation bmr,
 			 */
 			do
 			{
-				pg_atomic_fetch_and_u32(&existing_hdr->state, ~BM_VALID);
+				pg_atomic_fetch_and_u64(&existing_hdr->state, ~BM_VALID);
 			} while (!StartBufferIO(existing_hdr, true, false));
 		}
 		else
 		{
-			uint32		buf_state;
-			uint32		set_bits = 0;
+			uint64		buf_state;
+			uint64		set_bits = 0;
 
 			buf_state = LockBufHdr(victim_buf_hdr);
 
@@ -2927,7 +2927,7 @@ BufferIsDirty(Buffer buffer)
 		Assert(BufferIsLockedByMeInMode(buffer, BUFFER_LOCK_EXCLUSIVE));
 	}
 
-	return pg_atomic_read_u32(&bufHdr->state) & BM_DIRTY;
+	return pg_atomic_read_u64(&bufHdr->state) & BM_DIRTY;
 }
 
 /*
@@ -2943,8 +2943,8 @@ void
 MarkBufferDirty(Buffer buffer)
 {
 	BufferDesc *bufHdr;
-	uint32		buf_state;
-	uint32		old_buf_state;
+	uint64		buf_state;
+	uint64		old_buf_state;
 
 	if (!BufferIsValid(buffer))
 		elog(ERROR, "bad buffer ID: %d", buffer);
@@ -2964,7 +2964,7 @@ MarkBufferDirty(Buffer buffer)
 	 * NB: We have to wait for the buffer header spinlock to be not held, as
 	 * TerminateBufferIO() relies on the spinlock.
 	 */
-	old_buf_state = pg_atomic_read_u32(&bufHdr->state);
+	old_buf_state = pg_atomic_read_u64(&bufHdr->state);
 	for (;;)
 	{
 		if (old_buf_state & BM_LOCKED)
@@ -2975,7 +2975,7 @@ MarkBufferDirty(Buffer buffer)
 		Assert(BUF_STATE_GET_REFCOUNT(buf_state) > 0);
 		buf_state |= BM_DIRTY | BM_JUST_DIRTIED;
 
-		if (pg_atomic_compare_exchange_u32(&bufHdr->state, &old_buf_state,
+		if (pg_atomic_compare_exchange_u64(&bufHdr->state, &old_buf_state,
 										   buf_state))
 			break;
 	}
@@ -3079,10 +3079,10 @@ PinBuffer(BufferDesc *buf, BufferAccessStrategy strategy,
 
 	if (ref == NULL)
 	{
-		uint32		buf_state;
-		uint32		old_buf_state;
+		uint64		buf_state;
+		uint64		old_buf_state;
 
-		old_buf_state = pg_atomic_read_u32(&buf->state);
+		old_buf_state = pg_atomic_read_u64(&buf->state);
 		for (;;)
 		{
 			if (unlikely(skip_if_not_valid && !(old_buf_state & BM_VALID)))
@@ -3116,7 +3116,7 @@ PinBuffer(BufferDesc *buf, BufferAccessStrategy strategy,
 					buf_state += BUF_USAGECOUNT_ONE;
 			}
 
-			if (pg_atomic_compare_exchange_u32(&buf->state, &old_buf_state,
+			if (pg_atomic_compare_exchange_u64(&buf->state, &old_buf_state,
 											   buf_state))
 			{
 				result = (buf_state & BM_VALID) != 0;
@@ -3143,7 +3143,7 @@ PinBuffer(BufferDesc *buf, BufferAccessStrategy strategy,
 		 * that the buffer page is legitimately non-accessible here.  We
 		 * cannot meddle with that.
 		 */
-		result = (pg_atomic_read_u32(&buf->state) & BM_VALID) != 0;
+		result = (pg_atomic_read_u64(&buf->state) & BM_VALID) != 0;
 
 		Assert(ref->refcount > 0);
 		ref->refcount++;
@@ -3178,7 +3178,7 @@ PinBuffer(BufferDesc *buf, BufferAccessStrategy strategy,
 static void
 PinBuffer_Locked(BufferDesc *buf)
 {
-	uint32		old_buf_state;
+	uint64		old_buf_state;
 
 	/*
 	 * As explained, We don't expect any preexisting pins. That allows us to
@@ -3190,7 +3190,7 @@ PinBuffer_Locked(BufferDesc *buf)
 	 * Since we hold the buffer spinlock, we can update the buffer state and
 	 * release the lock in one operation.
 	 */
-	old_buf_state = pg_atomic_read_u32(&buf->state);
+	old_buf_state = pg_atomic_read_u64(&buf->state);
 
 	UnlockBufHdrExt(buf, old_buf_state,
 					0, 0, 1);
@@ -3220,7 +3220,7 @@ WakePinCountWaiter(BufferDesc *buf)
 	 * BM_PIN_COUNT_WAITER if it stops waiting for a reason other than this
 	 * backend waking it up.
 	 */
-	uint32		buf_state = LockBufHdr(buf);
+	uint64		buf_state = LockBufHdr(buf);
 
 	if ((buf_state & BM_PIN_COUNT_WAITER) &&
 		BUF_STATE_GET_REFCOUNT(buf_state) == 1)
@@ -3267,7 +3267,7 @@ UnpinBufferNoOwner(BufferDesc *buf)
 	ref->refcount--;
 	if (ref->refcount == 0)
 	{
-		uint32		old_buf_state;
+		uint64		old_buf_state;
 
 		/*
 		 * Mark buffer non-accessible to Valgrind.
@@ -3285,7 +3285,7 @@ UnpinBufferNoOwner(BufferDesc *buf)
 		Assert(!LWLockHeldByMe(BufferDescriptorGetContentLock(buf)));
 
 		/* decrement the shared reference count */
-		old_buf_state = pg_atomic_fetch_sub_u32(&buf->state, BUF_REFCOUNT_ONE);
+		old_buf_state = pg_atomic_fetch_sub_u64(&buf->state, BUF_REFCOUNT_ONE);
 
 		/* Support LockBufferForCleanup() */
 		if (old_buf_state & BM_PIN_COUNT_WAITER)
@@ -3342,7 +3342,7 @@ TrackNewBufferPin(Buffer buf)
 static void
 BufferSync(int flags)
 {
-	uint32		buf_state;
+	uint64		buf_state;
 	int			buf_id;
 	int			num_to_scan;
 	int			num_spaces;
@@ -3352,7 +3352,7 @@ BufferSync(int flags)
 	Oid			last_tsid;
 	binaryheap *ts_heap;
 	int			i;
-	uint32		mask = BM_DIRTY;
+	uint64		mask = BM_DIRTY;
 	WritebackContext wb_context;
 
 	/*
@@ -3384,7 +3384,7 @@ BufferSync(int flags)
 	for (buf_id = 0; buf_id < NBuffers; buf_id++)
 	{
 		BufferDesc *bufHdr = GetBufferDescriptor(buf_id);
-		uint32		set_bits = 0;
+		uint64		set_bits = 0;
 
 		/*
 		 * Header spinlock is enough to examine BM_DIRTY, see comment in
@@ -3551,7 +3551,7 @@ BufferSync(int flags)
 		 * write the buffer though we didn't need to.  It doesn't seem worth
 		 * guarding against this, though.
 		 */
-		if (pg_atomic_read_u32(&bufHdr->state) & BM_CHECKPOINT_NEEDED)
+		if (pg_atomic_read_u64(&bufHdr->state) & BM_CHECKPOINT_NEEDED)
 		{
 			if (SyncOneBuffer(buf_id, false, &wb_context) & BUF_WRITTEN)
 			{
@@ -3921,7 +3921,7 @@ SyncOneBuffer(int buf_id, bool skip_recently_used, WritebackContext *wb_context)
 {
 	BufferDesc *bufHdr = GetBufferDescriptor(buf_id);
 	int			result = 0;
-	uint32		buf_state;
+	uint64		buf_state;
 	BufferTag	tag;
 
 	/* Make sure we can handle the pin */
@@ -4169,7 +4169,7 @@ DebugPrintBufferRefcount(Buffer buffer)
 	int32		loccount;
 	char	   *result;
 	ProcNumber	backend;
-	uint32		buf_state;
+	uint64		buf_state;
 
 	Assert(BufferIsValid(buffer));
 	if (BufferIsLocal(buffer))
@@ -4186,9 +4186,9 @@ DebugPrintBufferRefcount(Buffer buffer)
 	}
 
 	/* theoretically we should lock the bufhdr here */
-	buf_state = pg_atomic_read_u32(&buf->state);
+	buf_state = pg_atomic_read_u64(&buf->state);
 
-	result = psprintf("[%03d] (rel=%s, blockNum=%u, flags=0x%x, refcount=%u %d)",
+	result = psprintf("[%03d] (rel=%s, blockNum=%u, flags=0x%" PRIx64 ", refcount=%u %d)",
 					  buffer,
 					  relpathbackend(BufTagGetRelFileLocator(&buf->tag), backend,
 									 BufTagGetForkNum(&buf->tag)).str,
@@ -4288,7 +4288,7 @@ FlushBuffer(BufferDesc *buf, SMgrRelation reln, IOObject io_object,
 	instr_time	io_start;
 	Block		bufBlock;
 	char	   *bufToWrite;
-	uint32		buf_state;
+	uint64		buf_state;
 
 	/*
 	 * Try to start an I/O operation.  If StartBufferIO returns false, then
@@ -4486,7 +4486,7 @@ BufferIsPermanent(Buffer buffer)
 	 * not random garbage.
 	 */
 	bufHdr = GetBufferDescriptor(buffer - 1);
-	return (pg_atomic_read_u32(&bufHdr->state) & BM_PERMANENT) != 0;
+	return (pg_atomic_read_u64(&bufHdr->state) & BM_PERMANENT) != 0;
 }
 
 /*
@@ -4949,11 +4949,11 @@ FlushRelationBuffers(Relation rel)
 	{
 		for (i = 0; i < NLocBuffer; i++)
 		{
-			uint32		buf_state;
+			uint64		buf_state;
 
 			bufHdr = GetLocalBufferDescriptor(i);
 			if (BufTagMatchesRelFileLocator(&bufHdr->tag, &rel->rd_locator) &&
-				((buf_state = pg_atomic_read_u32(&bufHdr->state)) &
+				((buf_state = pg_atomic_read_u64(&bufHdr->state)) &
 				 (BM_VALID | BM_DIRTY)) == (BM_VALID | BM_DIRTY))
 			{
 				ErrorContextCallback errcallback;
@@ -4989,7 +4989,7 @@ FlushRelationBuffers(Relation rel)
 
 	for (i = 0; i < NBuffers; i++)
 	{
-		uint32		buf_state;
+		uint64		buf_state;
 
 		bufHdr = GetBufferDescriptor(i);
 
@@ -5061,7 +5061,7 @@ FlushRelationsAllBuffers(SMgrRelation *smgrs, int nrels)
 	{
 		SMgrSortArray *srelent = NULL;
 		BufferDesc *bufHdr = GetBufferDescriptor(i);
-		uint32		buf_state;
+		uint64		buf_state;
 
 		/*
 		 * As in DropRelationBuffers, an unlocked precheck should be safe and
@@ -5310,7 +5310,7 @@ FlushDatabaseBuffers(Oid dbid)
 
 	for (i = 0; i < NBuffers; i++)
 	{
-		uint32		buf_state;
+		uint64		buf_state;
 
 		bufHdr = GetBufferDescriptor(i);
 
@@ -5458,13 +5458,13 @@ MarkBufferDirtyHint(Buffer buffer, bool buffer_std)
 	 * is only intended to be used in cases where failing to write out the
 	 * data would be harmless anyway, it doesn't really matter.
 	 */
-	if ((pg_atomic_read_u32(&bufHdr->state) & (BM_DIRTY | BM_JUST_DIRTIED)) !=
+	if ((pg_atomic_read_u64(&bufHdr->state) & (BM_DIRTY | BM_JUST_DIRTIED)) !=
 		(BM_DIRTY | BM_JUST_DIRTIED))
 	{
 		XLogRecPtr	lsn = InvalidXLogRecPtr;
 		bool		dirtied = false;
 		bool		delayChkptFlags = false;
-		uint32		buf_state;
+		uint64		buf_state;
 
 		/*
 		 * If we need to protect hint bit updates from torn writes, WAL-log a
@@ -5476,7 +5476,7 @@ MarkBufferDirtyHint(Buffer buffer, bool buffer_std)
 		 * when we call XLogInsert() since the value changes dynamically.
 		 */
 		if (XLogHintBitIsNeeded() &&
-			(pg_atomic_read_u32(&bufHdr->state) & BM_PERMANENT))
+			(pg_atomic_read_u64(&bufHdr->state) & BM_PERMANENT))
 		{
 			/*
 			 * If we must not write WAL, due to a relfilelocator-specific
@@ -5576,8 +5576,8 @@ UnlockBuffers(void)
 
 	if (buf)
 	{
-		uint32		buf_state;
-		uint32		unset_bits = 0;
+		uint64		buf_state;
+		uint64		unset_bits = 0;
 
 		buf_state = LockBufHdr(buf);
 
@@ -5708,8 +5708,8 @@ LockBufferForCleanup(Buffer buffer)
 
 	for (;;)
 	{
-		uint32		buf_state;
-		uint32		unset_bits = 0;
+		uint64		buf_state;
+		uint64		unset_bits = 0;
 
 		/* Try to acquire lock */
 		LockBuffer(buffer, BUFFER_LOCK_EXCLUSIVE);
@@ -5857,7 +5857,7 @@ bool
 ConditionalLockBufferForCleanup(Buffer buffer)
 {
 	BufferDesc *bufHdr;
-	uint32		buf_state,
+	uint64		buf_state,
 				refcount;
 
 	Assert(BufferIsValid(buffer));
@@ -5915,7 +5915,7 @@ bool
 IsBufferCleanupOK(Buffer buffer)
 {
 	BufferDesc *bufHdr;
-	uint32		buf_state;
+	uint64		buf_state;
 
 	Assert(BufferIsValid(buffer));
 
@@ -5971,7 +5971,7 @@ WaitIO(BufferDesc *buf)
 	ConditionVariablePrepareToSleep(cv);
 	for (;;)
 	{
-		uint32		buf_state;
+		uint64		buf_state;
 		PgAioWaitRef iow;
 
 		/*
@@ -6045,7 +6045,7 @@ WaitIO(BufferDesc *buf)
 bool
 StartBufferIO(BufferDesc *buf, bool forInput, bool nowait)
 {
-	uint32		buf_state;
+	uint64		buf_state;
 
 	ResourceOwnerEnlarge(CurrentResourceOwner);
 
@@ -6101,11 +6101,11 @@ StartBufferIO(BufferDesc *buf, bool forInput, bool nowait)
  * is being released)
  */
 void
-TerminateBufferIO(BufferDesc *buf, bool clear_dirty, uint32 set_flag_bits,
+TerminateBufferIO(BufferDesc *buf, bool clear_dirty, uint64 set_flag_bits,
 				  bool forget_owner, bool release_aio)
 {
-	uint32		buf_state;
-	uint32		unset_flag_bits = 0;
+	uint64		buf_state;
+	uint64		unset_flag_bits = 0;
 	int			refcount_change = 0;
 
 	buf_state = LockBufHdr(buf);
@@ -6166,7 +6166,7 @@ static void
 AbortBufferIO(Buffer buffer)
 {
 	BufferDesc *buf_hdr = GetBufferDescriptor(buffer - 1);
-	uint32		buf_state;
+	uint64		buf_state;
 
 	buf_state = LockBufHdr(buf_hdr);
 	Assert(buf_state & (BM_IO_IN_PROGRESS | BM_TAG_VALID));
@@ -6260,11 +6260,11 @@ rlocator_comparator(const void *p1, const void *p2)
 /*
  * Lock buffer header - set BM_LOCKED in buffer state.
  */
-uint32
+uint64
 LockBufHdr(BufferDesc *desc)
 {
 	SpinDelayStatus delayStatus;
-	uint32		old_buf_state;
+	uint64		old_buf_state;
 
 	Assert(!BufferIsLocal(BufferDescriptorGetBuffer(desc)));
 
@@ -6273,7 +6273,7 @@ LockBufHdr(BufferDesc *desc)
 	while (true)
 	{
 		/* set BM_LOCKED flag */
-		old_buf_state = pg_atomic_fetch_or_u32(&desc->state, BM_LOCKED);
+		old_buf_state = pg_atomic_fetch_or_u64(&desc->state, BM_LOCKED);
 		/* if it wasn't set before we're OK */
 		if (!(old_buf_state & BM_LOCKED))
 			break;
@@ -6290,20 +6290,20 @@ LockBufHdr(BufferDesc *desc)
  * Obviously the buffer could be locked by the time the value is returned, so
  * this is primarily useful in CAS style loops.
  */
-pg_noinline uint32
+pg_noinline uint64
 WaitBufHdrUnlocked(BufferDesc *buf)
 {
 	SpinDelayStatus delayStatus;
-	uint32		buf_state;
+	uint64		buf_state;
 
 	init_local_spin_delay(&delayStatus);
 
-	buf_state = pg_atomic_read_u32(&buf->state);
+	buf_state = pg_atomic_read_u64(&buf->state);
 
 	while (buf_state & BM_LOCKED)
 	{
 		perform_spin_delay(&delayStatus);
-		buf_state = pg_atomic_read_u32(&buf->state);
+		buf_state = pg_atomic_read_u64(&buf->state);
 	}
 
 	finish_spin_delay(&delayStatus);
@@ -6591,12 +6591,12 @@ ResOwnerPrintBufferPin(Datum res)
 static bool
 EvictUnpinnedBufferInternal(BufferDesc *desc, bool *buffer_flushed)
 {
-	uint32		buf_state;
+	uint64		buf_state;
 	bool		result;
 
 	*buffer_flushed = false;
 
-	buf_state = pg_atomic_read_u32(&(desc->state));
+	buf_state = pg_atomic_read_u64(&(desc->state));
 	Assert(buf_state & BM_LOCKED);
 
 	if ((buf_state & BM_VALID) == 0)
@@ -6690,12 +6690,12 @@ EvictAllUnpinnedBuffers(int32 *buffers_evicted, int32 *buffers_flushed,
 	for (int buf = 1; buf <= NBuffers; buf++)
 	{
 		BufferDesc *desc = GetBufferDescriptor(buf - 1);
-		uint32		buf_state;
+		uint64		buf_state;
 		bool		buffer_flushed;
 
 		CHECK_FOR_INTERRUPTS();
 
-		buf_state = pg_atomic_read_u32(&desc->state);
+		buf_state = pg_atomic_read_u64(&desc->state);
 		if (!(buf_state & BM_VALID))
 			continue;
 
@@ -6742,7 +6742,7 @@ EvictRelUnpinnedBuffers(Relation rel, int32 *buffers_evicted,
 	for (int buf = 1; buf <= NBuffers; buf++)
 	{
 		BufferDesc *desc = GetBufferDescriptor(buf - 1);
-		uint32		buf_state = pg_atomic_read_u32(&(desc->state));
+		uint64		buf_state = pg_atomic_read_u64(&(desc->state));
 		bool		buffer_flushed;
 
 		CHECK_FOR_INTERRUPTS();
@@ -6809,7 +6809,7 @@ buffer_stage_common(PgAioHandle *ioh, bool is_write, bool is_temp)
 		BufferDesc *buf_hdr = is_temp ?
 			GetLocalBufferDescriptor(-buffer - 1)
 			: GetBufferDescriptor(buffer - 1);
-		uint32		buf_state;
+		uint64		buf_state;
 
 		/*
 		 * Check that all the buffers are actually ones that could conceivably
@@ -6827,7 +6827,7 @@ buffer_stage_common(PgAioHandle *ioh, bool is_write, bool is_temp)
 		}
 
 		if (is_temp)
-			buf_state = pg_atomic_read_u32(&buf_hdr->state);
+			buf_state = pg_atomic_read_u64(&buf_hdr->state);
 		else
 			buf_state = LockBufHdr(buf_hdr);
 
@@ -6865,7 +6865,7 @@ buffer_stage_common(PgAioHandle *ioh, bool is_write, bool is_temp)
 		if (is_temp)
 		{
 			buf_state += BUF_REFCOUNT_ONE;
-			pg_atomic_unlocked_write_u32(&buf_hdr->state, buf_state);
+			pg_atomic_unlocked_write_u64(&buf_hdr->state, buf_state);
 		}
 		else
 			UnlockBufHdrExt(buf_hdr, buf_state, 0, 0, 1);
@@ -7051,13 +7051,13 @@ buffer_readv_complete_one(PgAioTargetData *td, uint8 buf_off, Buffer buffer,
 		: GetBufferDescriptor(buffer - 1);
 	BufferTag	tag = buf_hdr->tag;
 	char	   *bufdata = BufferGetBlock(buffer);
-	uint32		set_flag_bits;
+	uint64		set_flag_bits;
 	int			piv_flags;
 
 	/* check that the buffer is in the expected state for a read */
 #ifdef USE_ASSERT_CHECKING
 	{
-		uint32		buf_state = pg_atomic_read_u32(&buf_hdr->state);
+		uint64		buf_state = pg_atomic_read_u64(&buf_hdr->state);
 
 		Assert(buf_state & BM_TAG_VALID);
 		Assert(!(buf_state & BM_VALID));
diff --git a/src/backend/storage/buffer/freelist.c b/src/backend/storage/buffer/freelist.c
index 28d952b3534..1d4f19a9afd 100644
--- a/src/backend/storage/buffer/freelist.c
+++ b/src/backend/storage/buffer/freelist.c
@@ -86,7 +86,7 @@ typedef struct BufferAccessStrategyData
 
 /* Prototypes for internal functions */
 static BufferDesc *GetBufferFromRing(BufferAccessStrategy strategy,
-									 uint32 *buf_state);
+									 uint64 *buf_state);
 static void AddBufferToRing(BufferAccessStrategy strategy,
 							BufferDesc *buf);
 
@@ -171,7 +171,7 @@ ClockSweepTick(void)
  *	before returning.
  */
 BufferDesc *
-StrategyGetBuffer(BufferAccessStrategy strategy, uint32 *buf_state, bool *from_ring)
+StrategyGetBuffer(BufferAccessStrategy strategy, uint64 *buf_state, bool *from_ring)
 {
 	BufferDesc *buf;
 	int			bgwprocno;
@@ -230,8 +230,8 @@ StrategyGetBuffer(BufferAccessStrategy strategy, uint32 *buf_state, bool *from_r
 	trycounter = NBuffers;
 	for (;;)
 	{
-		uint32		old_buf_state;
-		uint32		local_buf_state;
+		uint64		old_buf_state;
+		uint64		local_buf_state;
 
 		buf = GetBufferDescriptor(ClockSweepTick());
 
@@ -239,7 +239,7 @@ StrategyGetBuffer(BufferAccessStrategy strategy, uint32 *buf_state, bool *from_r
 		 * Check whether the buffer can be used and pin it if so. Do this
 		 * using a CAS loop, to avoid having to lock the buffer header.
 		 */
-		old_buf_state = pg_atomic_read_u32(&buf->state);
+		old_buf_state = pg_atomic_read_u64(&buf->state);
 		for (;;)
 		{
 			local_buf_state = old_buf_state;
@@ -277,7 +277,7 @@ StrategyGetBuffer(BufferAccessStrategy strategy, uint32 *buf_state, bool *from_r
 			{
 				local_buf_state -= BUF_USAGECOUNT_ONE;
 
-				if (pg_atomic_compare_exchange_u32(&buf->state, &old_buf_state,
+				if (pg_atomic_compare_exchange_u64(&buf->state, &old_buf_state,
 												   local_buf_state))
 				{
 					trycounter = NBuffers;
@@ -289,7 +289,7 @@ StrategyGetBuffer(BufferAccessStrategy strategy, uint32 *buf_state, bool *from_r
 				/* pin the buffer if the CAS succeeds */
 				local_buf_state += BUF_REFCOUNT_ONE;
 
-				if (pg_atomic_compare_exchange_u32(&buf->state, &old_buf_state,
+				if (pg_atomic_compare_exchange_u64(&buf->state, &old_buf_state,
 												   local_buf_state))
 				{
 					/* Found a usable buffer */
@@ -655,12 +655,12 @@ FreeAccessStrategy(BufferAccessStrategy strategy)
  * returning.
  */
 static BufferDesc *
-GetBufferFromRing(BufferAccessStrategy strategy, uint32 *buf_state)
+GetBufferFromRing(BufferAccessStrategy strategy, uint64 *buf_state)
 {
 	BufferDesc *buf;
 	Buffer		bufnum;
-	uint32		old_buf_state;
-	uint32		local_buf_state;	/* to avoid repeated (de-)referencing */
+	uint64		old_buf_state;
+	uint64		local_buf_state;	/* to avoid repeated (de-)referencing */
 
 
 	/* Advance to next ring slot */
@@ -682,7 +682,7 @@ GetBufferFromRing(BufferAccessStrategy strategy, uint32 *buf_state)
 	 * Check whether the buffer can be used and pin it if so. Do this using a
 	 * CAS loop, to avoid having to lock the buffer header.
 	 */
-	old_buf_state = pg_atomic_read_u32(&buf->state);
+	old_buf_state = pg_atomic_read_u64(&buf->state);
 	for (;;)
 	{
 		local_buf_state = old_buf_state;
@@ -710,7 +710,7 @@ GetBufferFromRing(BufferAccessStrategy strategy, uint32 *buf_state)
 		/* pin the buffer if the CAS succeeds */
 		local_buf_state += BUF_REFCOUNT_ONE;
 
-		if (pg_atomic_compare_exchange_u32(&buf->state, &old_buf_state,
+		if (pg_atomic_compare_exchange_u64(&buf->state, &old_buf_state,
 										   local_buf_state))
 		{
 			*buf_state = local_buf_state;
diff --git a/src/backend/storage/buffer/localbuf.c b/src/backend/storage/buffer/localbuf.c
index 15aac7d1c9f..a41a5facd3a 100644
--- a/src/backend/storage/buffer/localbuf.c
+++ b/src/backend/storage/buffer/localbuf.c
@@ -148,7 +148,7 @@ LocalBufferAlloc(SMgrRelation smgr, ForkNumber forkNum, BlockNumber blockNum,
 	}
 	else
 	{
-		uint32		buf_state;
+		uint64		buf_state;
 
 		victim_buffer = GetLocalVictimBuffer();
 		bufid = -victim_buffer - 1;
@@ -165,10 +165,10 @@ LocalBufferAlloc(SMgrRelation smgr, ForkNumber forkNum, BlockNumber blockNum,
 		 */
 		bufHdr->tag = newTag;
 
-		buf_state = pg_atomic_read_u32(&bufHdr->state);
+		buf_state = pg_atomic_read_u64(&bufHdr->state);
 		buf_state &= ~(BUF_FLAG_MASK | BUF_USAGECOUNT_MASK);
 		buf_state |= BM_TAG_VALID | BUF_USAGECOUNT_ONE;
-		pg_atomic_unlocked_write_u32(&bufHdr->state, buf_state);
+		pg_atomic_unlocked_write_u64(&bufHdr->state, buf_state);
 
 		*foundPtr = false;
 	}
@@ -245,12 +245,12 @@ GetLocalVictimBuffer(void)
 
 		if (LocalRefCount[victim_bufid] == 0)
 		{
-			uint32		buf_state = pg_atomic_read_u32(&bufHdr->state);
+			uint64		buf_state = pg_atomic_read_u64(&bufHdr->state);
 
 			if (BUF_STATE_GET_USAGECOUNT(buf_state) > 0)
 			{
 				buf_state -= BUF_USAGECOUNT_ONE;
-				pg_atomic_unlocked_write_u32(&bufHdr->state, buf_state);
+				pg_atomic_unlocked_write_u64(&bufHdr->state, buf_state);
 				trycounter = NLocBuffer;
 			}
 			else if (BUF_STATE_GET_REFCOUNT(buf_state) > 0)
@@ -286,13 +286,13 @@ GetLocalVictimBuffer(void)
 	 * this buffer is not referenced but it might still be dirty. if that's
 	 * the case, write it out before reusing it!
 	 */
-	if (pg_atomic_read_u32(&bufHdr->state) & BM_DIRTY)
+	if (pg_atomic_read_u64(&bufHdr->state) & BM_DIRTY)
 		FlushLocalBuffer(bufHdr, NULL);
 
 	/*
 	 * Remove the victim buffer from the hashtable and mark as invalid.
 	 */
-	if (pg_atomic_read_u32(&bufHdr->state) & BM_TAG_VALID)
+	if (pg_atomic_read_u64(&bufHdr->state) & BM_TAG_VALID)
 	{
 		InvalidateLocalBuffer(bufHdr, false);
 
@@ -417,7 +417,7 @@ ExtendBufferedRelLocal(BufferManagerRelation bmr,
 		if (found)
 		{
 			BufferDesc *existing_hdr;
-			uint32		buf_state;
+			uint64		buf_state;
 
 			UnpinLocalBuffer(BufferDescriptorGetBuffer(victim_buf_hdr));
 
@@ -428,18 +428,18 @@ ExtendBufferedRelLocal(BufferManagerRelation bmr,
 			/*
 			 * Clear the BM_VALID bit, do StartLocalBufferIO() and proceed.
 			 */
-			buf_state = pg_atomic_read_u32(&existing_hdr->state);
+			buf_state = pg_atomic_read_u64(&existing_hdr->state);
 			Assert(buf_state & BM_TAG_VALID);
 			Assert(!(buf_state & BM_DIRTY));
 			buf_state &= ~BM_VALID;
-			pg_atomic_unlocked_write_u32(&existing_hdr->state, buf_state);
+			pg_atomic_unlocked_write_u64(&existing_hdr->state, buf_state);
 
 			/* no need to loop for local buffers */
 			StartLocalBufferIO(existing_hdr, true, false);
 		}
 		else
 		{
-			uint32		buf_state = pg_atomic_read_u32(&victim_buf_hdr->state);
+			uint64		buf_state = pg_atomic_read_u64(&victim_buf_hdr->state);
 
 			Assert(!(buf_state & (BM_VALID | BM_TAG_VALID | BM_DIRTY | BM_JUST_DIRTIED)));
 
@@ -447,7 +447,7 @@ ExtendBufferedRelLocal(BufferManagerRelation bmr,
 
 			buf_state |= BM_TAG_VALID | BUF_USAGECOUNT_ONE;
 
-			pg_atomic_unlocked_write_u32(&victim_buf_hdr->state, buf_state);
+			pg_atomic_unlocked_write_u64(&victim_buf_hdr->state, buf_state);
 
 			hresult->id = victim_buf_id;
 
@@ -467,13 +467,13 @@ ExtendBufferedRelLocal(BufferManagerRelation bmr,
 	{
 		Buffer		buf = buffers[i];
 		BufferDesc *buf_hdr;
-		uint32		buf_state;
+		uint64		buf_state;
 
 		buf_hdr = GetLocalBufferDescriptor(-buf - 1);
 
-		buf_state = pg_atomic_read_u32(&buf_hdr->state);
+		buf_state = pg_atomic_read_u64(&buf_hdr->state);
 		buf_state |= BM_VALID;
-		pg_atomic_unlocked_write_u32(&buf_hdr->state, buf_state);
+		pg_atomic_unlocked_write_u64(&buf_hdr->state, buf_state);
 	}
 
 	*extended_by = extend_by;
@@ -492,7 +492,7 @@ MarkLocalBufferDirty(Buffer buffer)
 {
 	int			bufid;
 	BufferDesc *bufHdr;
-	uint32		buf_state;
+	uint64		buf_state;
 
 	Assert(BufferIsLocal(buffer));
 
@@ -506,14 +506,14 @@ MarkLocalBufferDirty(Buffer buffer)
 
 	bufHdr = GetLocalBufferDescriptor(bufid);
 
-	buf_state = pg_atomic_read_u32(&bufHdr->state);
+	buf_state = pg_atomic_read_u64(&bufHdr->state);
 
 	if (!(buf_state & BM_DIRTY))
 		pgBufferUsage.local_blks_dirtied++;
 
 	buf_state |= BM_DIRTY;
 
-	pg_atomic_unlocked_write_u32(&bufHdr->state, buf_state);
+	pg_atomic_unlocked_write_u64(&bufHdr->state, buf_state);
 }
 
 /*
@@ -522,7 +522,7 @@ MarkLocalBufferDirty(Buffer buffer)
 bool
 StartLocalBufferIO(BufferDesc *bufHdr, bool forInput, bool nowait)
 {
-	uint32		buf_state;
+	uint64		buf_state;
 
 	/*
 	 * With AIO the buffer could have IO in progress, e.g. when there are two
@@ -542,7 +542,7 @@ StartLocalBufferIO(BufferDesc *bufHdr, bool forInput, bool nowait)
 	/* Once we get here, there is definitely no I/O active on this buffer */
 
 	/* Check if someone else already did the I/O */
-	buf_state = pg_atomic_read_u32(&bufHdr->state);
+	buf_state = pg_atomic_read_u64(&bufHdr->state);
 	if (forInput ? (buf_state & BM_VALID) : !(buf_state & BM_DIRTY))
 	{
 		return false;
@@ -559,11 +559,11 @@ StartLocalBufferIO(BufferDesc *bufHdr, bool forInput, bool nowait)
  * Like TerminateBufferIO, but for local buffers
  */
 void
-TerminateLocalBufferIO(BufferDesc *bufHdr, bool clear_dirty, uint32 set_flag_bits,
+TerminateLocalBufferIO(BufferDesc *bufHdr, bool clear_dirty, uint64 set_flag_bits,
 					   bool release_aio)
 {
 	/* Only need to adjust flags */
-	uint32		buf_state = pg_atomic_read_u32(&bufHdr->state);
+	uint64		buf_state = pg_atomic_read_u64(&bufHdr->state);
 
 	/* BM_IO_IN_PROGRESS isn't currently used for local buffers */
 
@@ -582,7 +582,7 @@ TerminateLocalBufferIO(BufferDesc *bufHdr, bool clear_dirty, uint32 set_flag_bit
 	}
 
 	buf_state |= set_flag_bits;
-	pg_atomic_unlocked_write_u32(&bufHdr->state, buf_state);
+	pg_atomic_unlocked_write_u64(&bufHdr->state, buf_state);
 
 	/* local buffers don't track IO using resowners */
 
@@ -606,7 +606,7 @@ InvalidateLocalBuffer(BufferDesc *bufHdr, bool check_unreferenced)
 {
 	Buffer		buffer = BufferDescriptorGetBuffer(bufHdr);
 	int			bufid = -buffer - 1;
-	uint32		buf_state;
+	uint64		buf_state;
 	LocalBufferLookupEnt *hresult;
 
 	/*
@@ -622,7 +622,7 @@ InvalidateLocalBuffer(BufferDesc *bufHdr, bool check_unreferenced)
 		Assert(!pgaio_wref_valid(&bufHdr->io_wref));
 	}
 
-	buf_state = pg_atomic_read_u32(&bufHdr->state);
+	buf_state = pg_atomic_read_u64(&bufHdr->state);
 
 	/*
 	 * We need to test not just LocalRefCount[bufid] but also the BufferDesc
@@ -647,7 +647,7 @@ InvalidateLocalBuffer(BufferDesc *bufHdr, bool check_unreferenced)
 	ClearBufferTag(&bufHdr->tag);
 	buf_state &= ~BUF_FLAG_MASK;
 	buf_state &= ~BUF_USAGECOUNT_MASK;
-	pg_atomic_unlocked_write_u32(&bufHdr->state, buf_state);
+	pg_atomic_unlocked_write_u64(&bufHdr->state, buf_state);
 }
 
 /*
@@ -671,9 +671,9 @@ DropRelationLocalBuffers(RelFileLocator rlocator, ForkNumber *forkNum,
 	for (i = 0; i < NLocBuffer; i++)
 	{
 		BufferDesc *bufHdr = GetLocalBufferDescriptor(i);
-		uint32		buf_state;
+		uint64		buf_state;
 
-		buf_state = pg_atomic_read_u32(&bufHdr->state);
+		buf_state = pg_atomic_read_u64(&bufHdr->state);
 
 		if (!(buf_state & BM_TAG_VALID) ||
 			!BufTagMatchesRelFileLocator(&bufHdr->tag, &rlocator))
@@ -706,9 +706,9 @@ DropRelationAllLocalBuffers(RelFileLocator rlocator)
 	for (i = 0; i < NLocBuffer; i++)
 	{
 		BufferDesc *bufHdr = GetLocalBufferDescriptor(i);
-		uint32		buf_state;
+		uint64		buf_state;
 
-		buf_state = pg_atomic_read_u32(&bufHdr->state);
+		buf_state = pg_atomic_read_u64(&bufHdr->state);
 
 		if ((buf_state & BM_TAG_VALID) &&
 			BufTagMatchesRelFileLocator(&bufHdr->tag, &rlocator))
@@ -804,11 +804,11 @@ InitLocalBuffers(void)
 bool
 PinLocalBuffer(BufferDesc *buf_hdr, bool adjust_usagecount)
 {
-	uint32		buf_state;
+	uint64		buf_state;
 	Buffer		buffer = BufferDescriptorGetBuffer(buf_hdr);
 	int			bufid = -buffer - 1;
 
-	buf_state = pg_atomic_read_u32(&buf_hdr->state);
+	buf_state = pg_atomic_read_u64(&buf_hdr->state);
 
 	if (LocalRefCount[bufid] == 0)
 	{
@@ -819,7 +819,7 @@ PinLocalBuffer(BufferDesc *buf_hdr, bool adjust_usagecount)
 		{
 			buf_state += BUF_USAGECOUNT_ONE;
 		}
-		pg_atomic_unlocked_write_u32(&buf_hdr->state, buf_state);
+		pg_atomic_unlocked_write_u64(&buf_hdr->state, buf_state);
 
 		/*
 		 * See comment in PinBuffer().
@@ -856,14 +856,14 @@ UnpinLocalBufferNoOwner(Buffer buffer)
 	if (--LocalRefCount[buffid] == 0)
 	{
 		BufferDesc *buf_hdr = GetLocalBufferDescriptor(buffid);
-		uint32		buf_state;
+		uint64		buf_state;
 
 		NLocalPinnedBuffers--;
 
-		buf_state = pg_atomic_read_u32(&buf_hdr->state);
+		buf_state = pg_atomic_read_u64(&buf_hdr->state);
 		Assert(BUF_STATE_GET_REFCOUNT(buf_state) > 0);
 		buf_state -= BUF_REFCOUNT_ONE;
-		pg_atomic_unlocked_write_u32(&buf_hdr->state, buf_state);
+		pg_atomic_unlocked_write_u64(&buf_hdr->state, buf_state);
 
 		/* see comment in UnpinBufferNoOwner */
 		VALGRIND_MAKE_MEM_NOACCESS(LocalBufHdrGetBlock(buf_hdr), BLCKSZ);
diff --git a/contrib/pg_buffercache/pg_buffercache_pages.c b/contrib/pg_buffercache/pg_buffercache_pages.c
index c29b784dfa1..32bd8aa784a 100644
--- a/contrib/pg_buffercache/pg_buffercache_pages.c
+++ b/contrib/pg_buffercache/pg_buffercache_pages.c
@@ -192,7 +192,7 @@ pg_buffercache_pages(PG_FUNCTION_ARGS)
 		for (i = 0; i < NBuffers; i++)
 		{
 			BufferDesc *bufHdr;
-			uint32		buf_state;
+			uint64		buf_state;
 
 			CHECK_FOR_INTERRUPTS();
 
@@ -559,7 +559,7 @@ pg_buffercache_summary(PG_FUNCTION_ARGS)
 	for (int i = 0; i < NBuffers; i++)
 	{
 		BufferDesc *bufHdr;
-		uint32		buf_state;
+		uint64		buf_state;
 
 		CHECK_FOR_INTERRUPTS();
 
@@ -570,7 +570,7 @@ pg_buffercache_summary(PG_FUNCTION_ARGS)
 		 * noticeably increase the cost of the function.
 		 */
 		bufHdr = GetBufferDescriptor(i);
-		buf_state = pg_atomic_read_u32(&bufHdr->state);
+		buf_state = pg_atomic_read_u64(&bufHdr->state);
 
 		if (buf_state & BM_VALID)
 		{
@@ -620,7 +620,7 @@ pg_buffercache_usage_counts(PG_FUNCTION_ARGS)
 	for (int i = 0; i < NBuffers; i++)
 	{
 		BufferDesc *bufHdr = GetBufferDescriptor(i);
-		uint32		buf_state = pg_atomic_read_u32(&bufHdr->state);
+		uint64		buf_state = pg_atomic_read_u64(&bufHdr->state);
 		int			usage_count;
 
 		CHECK_FOR_INTERRUPTS();
diff --git a/src/test/modules/test_aio/test_aio.c b/src/test/modules/test_aio/test_aio.c
index d7eadeab256..488d98e7e66 100644
--- a/src/test/modules/test_aio/test_aio.c
+++ b/src/test/modules/test_aio/test_aio.c
@@ -308,9 +308,9 @@ create_toy_buffer(Relation rel, BlockNumber blkno)
 {
 	Buffer		buf;
 	BufferDesc *buf_hdr;
-	uint32		buf_state;
+	uint64		buf_state;
 	bool		was_pinned = false;
-	uint32		unset_bits = 0;
+	uint64		unset_bits = 0;
 
 	/* place buffer in shared buffers without erroring out */
 	buf = ReadBufferExtended(rel, MAIN_FORKNUM, blkno, RBM_ZERO_AND_LOCK, NULL);
@@ -319,7 +319,7 @@ create_toy_buffer(Relation rel, BlockNumber blkno)
 	if (RelationUsesLocalBuffers(rel))
 	{
 		buf_hdr = GetLocalBufferDescriptor(-buf - 1);
-		buf_state = pg_atomic_read_u32(&buf_hdr->state);
+		buf_state = pg_atomic_read_u64(&buf_hdr->state);
 	}
 	else
 	{
@@ -340,7 +340,7 @@ create_toy_buffer(Relation rel, BlockNumber blkno)
 	if (RelationUsesLocalBuffers(rel))
 	{
 		buf_state &= ~unset_bits;
-		pg_atomic_unlocked_write_u32(&buf_hdr->state, buf_state);
+		pg_atomic_unlocked_write_u64(&buf_hdr->state, buf_state);
 	}
 	else
 	{
@@ -489,7 +489,7 @@ invalidate_rel_block(PG_FUNCTION_ARGS)
 
 			LockBuffer(buf, BUFFER_LOCK_EXCLUSIVE);
 
-			if (pg_atomic_read_u32(&buf_hdr->state) & BM_DIRTY)
+			if (pg_atomic_read_u64(&buf_hdr->state) & BM_DIRTY)
 			{
 				if (BufferIsLocal(buf))
 					FlushLocalBuffer(buf_hdr, NULL);
@@ -572,7 +572,7 @@ buffer_call_terminate_io(PG_FUNCTION_ARGS)
 	bool		io_error = PG_GETARG_BOOL(3);
 	bool		release_aio = PG_GETARG_BOOL(4);
 	bool		clear_dirty = false;
-	uint32		set_flag_bits = 0;
+	uint64		set_flag_bits = 0;
 
 	if (io_error)
 		set_flag_bits |= BM_IO_ERROR;
-- 
2.48.1.76.g4e746b1a31.dirty


--mhhc7c45w3dmihtp
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
	filename="v6-0005-Rename-BUFFERPIN-wait-event-class-to-BUFFER.patch"



^ permalink  raw  reply  [nested|flat] 129+ messages in thread

* [PATCH v7 11/15] bufmgr: Change BufferDesc.state to be a 64bit atomic
@ 2025-12-02 23:46  Andres Freund <andres@anarazel.de>
  0 siblings, 0 replies; 129+ messages in thread

From: Andres Freund @ 2025-12-02 23:46 UTC (permalink / raw)

This is motivated by wanting to merge buffer content locks into
BufferDesc.state in a future commit, rather than having a separate lwlock (see
commit c75ebc657ff more details). As this change is rather mechanical, it
seems to make sense to split it out into a separate commit, for easier review.

Reviewed-by: Melanie Plageman <melanieplageman@gmail.com>
Discussion: https://postgr.es/m/fvfmkr5kk4nyex56ejgxj3uzi63isfxovp2biecb4bspbjrze7@az2pljabhnff
---
 src/include/storage/buf_internals.h           |  88 +++++----
 src/include/storage/procnumber.h              |  14 +-
 src/backend/storage/buffer/buf_init.c         |   2 +-
 src/backend/storage/buffer/bufmgr.c           | 170 +++++++++---------
 src/backend/storage/buffer/freelist.c         |  24 +--
 src/backend/storage/buffer/localbuf.c         |  72 ++++----
 contrib/pg_buffercache/pg_buffercache_pages.c |   8 +-
 src/test/modules/test_aio/test_aio.c          |  12 +-
 8 files changed, 205 insertions(+), 185 deletions(-)

diff --git a/src/include/storage/buf_internals.h b/src/include/storage/buf_internals.h
index 5400c56a965..28519ad2813 100644
--- a/src/include/storage/buf_internals.h
+++ b/src/include/storage/buf_internals.h
@@ -30,7 +30,7 @@
 #include "utils/resowner.h"
 
 /*
- * Buffer state is a single 32-bit variable where following data is combined.
+ * Buffer state is a single 64-bit variable where following data is combined.
  *
  * - 18 bits refcount
  * - 4 bits usage count
@@ -39,6 +39,9 @@
  * Combining these values allows to perform some operations without locking
  * the buffer header, by modifying them together with a CAS loop.
  *
+ * NB: A future commit will use a significant portion of the remaining bits to
+ * implement buffer locking as part of the state variable.
+ *
  * The definition of buffer state components is below.
  */
 #define BUF_REFCOUNT_BITS 18
@@ -49,15 +52,21 @@ StaticAssertDecl(BUF_REFCOUNT_BITS + BUF_USAGECOUNT_BITS + BUF_FLAG_BITS == 32,
 				 "parts of buffer state space need to equal 32");
 
 #define BUF_REFCOUNT_ONE 1
-#define BUF_REFCOUNT_MASK ((1U << BUF_REFCOUNT_BITS) - 1)
-#define BUF_USAGECOUNT_MASK (((1U << BUF_USAGECOUNT_BITS) - 1) << (BUF_REFCOUNT_BITS))
-#define BUF_USAGECOUNT_ONE (1U << BUF_REFCOUNT_BITS)
+#define BUF_REFCOUNT_MASK \
+	((UINT64CONST(1) << BUF_REFCOUNT_BITS) - 1)
+#define BUF_USAGECOUNT_MASK \
+	(((UINT64CONST(1) << BUF_USAGECOUNT_BITS) - 1) << (BUF_REFCOUNT_BITS))
+#define BUF_USAGECOUNT_ONE \
+	(UINT64CONST(1) << BUF_REFCOUNT_BITS)
 #define BUF_USAGECOUNT_SHIFT BUF_REFCOUNT_BITS
-#define BUF_FLAG_MASK (((1U << BUF_FLAG_BITS) - 1) << (BUF_REFCOUNT_BITS + BUF_USAGECOUNT_BITS))
+#define BUF_FLAG_MASK \
+	(((UINT64CONST(1) << BUF_FLAG_BITS) - 1) << (BUF_REFCOUNT_BITS + BUF_USAGECOUNT_BITS))
 
 /* Get refcount and usagecount from buffer state */
-#define BUF_STATE_GET_REFCOUNT(state) ((state) & BUF_REFCOUNT_MASK)
-#define BUF_STATE_GET_USAGECOUNT(state) (((state) & BUF_USAGECOUNT_MASK) >> BUF_USAGECOUNT_SHIFT)
+#define BUF_STATE_GET_REFCOUNT(state) \
+	((uint32)((state) & BUF_REFCOUNT_MASK))
+#define BUF_STATE_GET_USAGECOUNT(state) \
+	((uint32)(((state) & BUF_USAGECOUNT_MASK) >> BUF_USAGECOUNT_SHIFT))
 
 /*
  * Flags for buffer descriptors
@@ -65,17 +74,28 @@ StaticAssertDecl(BUF_REFCOUNT_BITS + BUF_USAGECOUNT_BITS + BUF_FLAG_BITS == 32,
  * Note: BM_TAG_VALID essentially means that there is a buffer hashtable
  * entry associated with the buffer's tag.
  */
-#define BM_LOCKED				(1U << 22)	/* buffer header is locked */
-#define BM_DIRTY				(1U << 23)	/* data needs writing */
-#define BM_VALID				(1U << 24)	/* data is valid */
-#define BM_TAG_VALID			(1U << 25)	/* tag is assigned */
-#define BM_IO_IN_PROGRESS		(1U << 26)	/* read or write in progress */
-#define BM_IO_ERROR				(1U << 27)	/* previous I/O failed */
-#define BM_JUST_DIRTIED			(1U << 28)	/* dirtied since write started */
-#define BM_PIN_COUNT_WAITER		(1U << 29)	/* have waiter for sole pin */
-#define BM_CHECKPOINT_NEEDED	(1U << 30)	/* must write for checkpoint */
-#define BM_PERMANENT			(1U << 31)	/* permanent buffer (not unlogged,
-											 * or init fork) */
+
+/* buffer header is locked */
+#define BM_LOCKED				(UINT64CONST(1) << 22)
+/* data needs writing */
+#define BM_DIRTY				(UINT64CONST(1) << 23)
+/* data is valid */
+#define BM_VALID				(UINT64CONST(1) << 24)
+/* tag is assigned */
+#define BM_TAG_VALID			(UINT64CONST(1) << 25)
+/* read or write in progress */
+#define BM_IO_IN_PROGRESS		(UINT64CONST(1) << 26)
+/* previous I/O failed */
+#define BM_IO_ERROR				(UINT64CONST(1) << 27)
+/* dirtied since write started */
+#define BM_JUST_DIRTIED			(UINT64CONST(1) << 28)
+/* have waiter for sole pin */
+#define BM_PIN_COUNT_WAITER		(UINT64CONST(1) << 29)
+/* must write for checkpoint */
+#define BM_CHECKPOINT_NEEDED	(UINT64CONST(1) << 30)
+/* permanent buffer (not unlogged, or init fork) */
+#define BM_PERMANENT			(UINT64CONST(1) << 31)
+
 /*
  * The maximum allowed value of usage_count represents a tradeoff between
  * accuracy and speed of the clock-sweep buffer management algorithm.  A
@@ -86,7 +106,7 @@ StaticAssertDecl(BUF_REFCOUNT_BITS + BUF_USAGECOUNT_BITS + BUF_FLAG_BITS == 32,
  */
 #define BM_MAX_USAGE_COUNT	5
 
-StaticAssertDecl(BM_MAX_USAGE_COUNT < (1 << BUF_USAGECOUNT_BITS),
+StaticAssertDecl(BM_MAX_USAGE_COUNT < (UINT64CONST(1) << BUF_USAGECOUNT_BITS),
 				 "BM_MAX_USAGE_COUNT doesn't fit in BUF_USAGECOUNT_BITS bits");
 StaticAssertDecl(MAX_BACKENDS_BITS <= BUF_REFCOUNT_BITS,
 				 "MAX_BACKENDS_BITS needs to be <= BUF_REFCOUNT_BITS");
@@ -251,8 +271,8 @@ BufMappingPartitionLockByIndex(uint32 index)
  * We use this same struct for local buffer headers, but the locks are not
  * used and not all of the flag bits are useful either. To avoid unnecessary
  * overhead, manipulations of the state field should be done without actual
- * atomic operations (i.e. only pg_atomic_read_u32() and
- * pg_atomic_unlocked_write_u32()).
+ * atomic operations (i.e. only pg_atomic_read_u64() and
+ * pg_atomic_unlocked_write_u64()).
  *
  * Be careful to avoid increasing the size of the struct when adding or
  * reordering members.  Keeping it below 64 bytes (the most common CPU
@@ -280,7 +300,7 @@ typedef struct BufferDesc
 	 * State of the buffer, containing flags, refcount and usagecount. See
 	 * BUF_* and BM_* defines at the top of this file.
 	 */
-	pg_atomic_uint32 state;
+	pg_atomic_uint64 state;
 
 	/*
 	 * Backend of pin-count waiter. The buffer header spinlock needs to be
@@ -386,7 +406,7 @@ BufferDescriptorGetContentLock(const BufferDesc *bdesc)
  * Functions for acquiring/releasing a shared buffer header's spinlock.  Do
  * not apply these to local buffers!
  */
-extern uint32 LockBufHdr(BufferDesc *desc);
+extern uint64 LockBufHdr(BufferDesc *desc);
 
 /*
  * Unlock the buffer header.
@@ -397,9 +417,9 @@ extern uint32 LockBufHdr(BufferDesc *desc);
 static inline void
 UnlockBufHdr(BufferDesc *desc)
 {
-	Assert(pg_atomic_read_u32(&desc->state) & BM_LOCKED);
+	Assert(pg_atomic_read_u64(&desc->state) & BM_LOCKED);
 
-	pg_atomic_fetch_sub_u32(&desc->state, BM_LOCKED);
+	pg_atomic_fetch_sub_u64(&desc->state, BM_LOCKED);
 }
 
 /*
@@ -410,14 +430,14 @@ UnlockBufHdr(BufferDesc *desc)
  * Note that this approach would not work for usagecount, since we need to cap
  * the usagecount at BM_MAX_USAGE_COUNT.
  */
-static inline uint32
-UnlockBufHdrExt(BufferDesc *desc, uint32 old_buf_state,
-				uint32 set_bits, uint32 unset_bits,
+static inline uint64
+UnlockBufHdrExt(BufferDesc *desc, uint64 old_buf_state,
+				uint64 set_bits, uint64 unset_bits,
 				int refcount_change)
 {
 	for (;;)
 	{
-		uint32		buf_state = old_buf_state;
+		uint64		buf_state = old_buf_state;
 
 		Assert(buf_state & BM_LOCKED);
 
@@ -428,7 +448,7 @@ UnlockBufHdrExt(BufferDesc *desc, uint32 old_buf_state,
 		if (refcount_change != 0)
 			buf_state += BUF_REFCOUNT_ONE * refcount_change;
 
-		if (pg_atomic_compare_exchange_u32(&desc->state, &old_buf_state,
+		if (pg_atomic_compare_exchange_u64(&desc->state, &old_buf_state,
 										   buf_state))
 		{
 			return old_buf_state;
@@ -436,7 +456,7 @@ UnlockBufHdrExt(BufferDesc *desc, uint32 old_buf_state,
 	}
 }
 
-extern uint32 WaitBufHdrUnlocked(BufferDesc *buf);
+extern uint64 WaitBufHdrUnlocked(BufferDesc *buf);
 
 /* in bufmgr.c */
 
@@ -496,14 +516,14 @@ extern void TrackNewBufferPin(Buffer buf);
 
 /* solely to make it easier to write tests */
 extern bool StartBufferIO(BufferDesc *buf, bool forInput, bool nowait);
-extern void TerminateBufferIO(BufferDesc *buf, bool clear_dirty, uint32 set_flag_bits,
+extern void TerminateBufferIO(BufferDesc *buf, bool clear_dirty, uint64 set_flag_bits,
 							  bool forget_owner, bool release_aio);
 
 
 /* freelist.c */
 extern IOContext IOContextForStrategy(BufferAccessStrategy strategy);
 extern BufferDesc *StrategyGetBuffer(BufferAccessStrategy strategy,
-									 uint32 *buf_state, bool *from_ring);
+									 uint64 *buf_state, bool *from_ring);
 extern bool StrategyRejectBuffer(BufferAccessStrategy strategy,
 								 BufferDesc *buf, bool from_ring);
 
@@ -539,7 +559,7 @@ extern BlockNumber ExtendBufferedRelLocal(BufferManagerRelation bmr,
 										  uint32 *extended_by);
 extern void MarkLocalBufferDirty(Buffer buffer);
 extern void TerminateLocalBufferIO(BufferDesc *bufHdr, bool clear_dirty,
-								   uint32 set_flag_bits, bool release_aio);
+								   uint64 set_flag_bits, bool release_aio);
 extern bool StartLocalBufferIO(BufferDesc *bufHdr, bool forInput, bool nowait);
 extern void FlushLocalBuffer(BufferDesc *bufHdr, SMgrRelation reln);
 extern void InvalidateLocalBuffer(BufferDesc *bufHdr, bool check_unreferenced);
diff --git a/src/include/storage/procnumber.h b/src/include/storage/procnumber.h
index 2ddaaf0c646..6baac7c77f1 100644
--- a/src/include/storage/procnumber.h
+++ b/src/include/storage/procnumber.h
@@ -27,13 +27,13 @@ typedef int ProcNumber;
 
 /*
  * Note: MAX_BACKENDS_BITS is 18 as that is the space available for buffer
- * refcounts in buf_internals.h.  This limitation could be lifted by using a
- * 64bit state; but it's unlikely to be worthwhile as 2^18-1 backends exceed
- * currently realistic configurations. Even if that limitation were removed,
- * we still could not a) exceed 2^23-1 because inval.c stores the ProcNumber
- * as a 3-byte signed integer, b) INT_MAX/4 because some places compute
- * 4*MaxBackends without any overflow check.  We check that the configured
- * number of backends does not exceed MAX_BACKENDS in InitializeMaxBackends().
+ * refcounts in buf_internals.h.  This limitation could be lifted, but it's
+ * unlikely to be worthwhile as 2^18-1 backends exceed currently realistic
+ * configurations. Even if that limitation were removed, we still could not a)
+ * exceed 2^23-1 because inval.c stores the ProcNumber as a 3-byte signed
+ * integer, b) INT_MAX/4 because some places compute 4*MaxBackends without any
+ * overflow check.  We check that the configured number of backends does not
+ * exceed MAX_BACKENDS in InitializeMaxBackends().
  */
 #define MAX_BACKENDS_BITS		18
 #define MAX_BACKENDS			((1U << MAX_BACKENDS_BITS)-1)
diff --git a/src/backend/storage/buffer/buf_init.c b/src/backend/storage/buffer/buf_init.c
index 6fd3a6bbac5..25f71191ec3 100644
--- a/src/backend/storage/buffer/buf_init.c
+++ b/src/backend/storage/buffer/buf_init.c
@@ -121,7 +121,7 @@ BufferManagerShmemInit(void)
 
 			ClearBufferTag(&buf->tag);
 
-			pg_atomic_init_u32(&buf->state, 0);
+			pg_atomic_init_u64(&buf->state, 0);
 			buf->wait_backend_pgprocno = INVALID_PROC_NUMBER;
 
 			buf->buf_id = i;
diff --git a/src/backend/storage/buffer/bufmgr.c b/src/backend/storage/buffer/bufmgr.c
index be32bd596f6..d0b8f8d20eb 100644
--- a/src/backend/storage/buffer/bufmgr.c
+++ b/src/backend/storage/buffer/bufmgr.c
@@ -775,7 +775,7 @@ ReadRecentBuffer(RelFileLocator rlocator, ForkNumber forkNum, BlockNumber blockN
 {
 	BufferDesc *bufHdr;
 	BufferTag	tag;
-	uint32		buf_state;
+	uint64		buf_state;
 
 	Assert(BufferIsValid(recent_buffer));
 
@@ -788,7 +788,7 @@ ReadRecentBuffer(RelFileLocator rlocator, ForkNumber forkNum, BlockNumber blockN
 		int			b = -recent_buffer - 1;
 
 		bufHdr = GetLocalBufferDescriptor(b);
-		buf_state = pg_atomic_read_u32(&bufHdr->state);
+		buf_state = pg_atomic_read_u64(&bufHdr->state);
 
 		/* Is it still valid and holding the right tag? */
 		if ((buf_state & BM_VALID) && BufferTagsEqual(&tag, &bufHdr->tag))
@@ -1381,8 +1381,8 @@ StartReadBuffersImpl(ReadBuffersOperation *operation,
 				bufHdr = GetLocalBufferDescriptor(-buffers[i] - 1);
 			else
 				bufHdr = GetBufferDescriptor(buffers[i] - 1);
-			Assert(pg_atomic_read_u32(&bufHdr->state) & BM_TAG_VALID);
-			found = pg_atomic_read_u32(&bufHdr->state) & BM_VALID;
+			Assert(pg_atomic_read_u64(&bufHdr->state) & BM_TAG_VALID);
+			found = pg_atomic_read_u64(&bufHdr->state) & BM_VALID;
 		}
 		else
 		{
@@ -1608,10 +1608,10 @@ CheckReadBuffersOperation(ReadBuffersOperation *operation, bool is_complete)
 			GetBufferDescriptor(buffer - 1);
 
 		Assert(BufferGetBlockNumber(buffer) == operation->blocknum + i);
-		Assert(pg_atomic_read_u32(&buf_hdr->state) & BM_TAG_VALID);
+		Assert(pg_atomic_read_u64(&buf_hdr->state) & BM_TAG_VALID);
 
 		if (i < operation->nblocks_done)
-			Assert(pg_atomic_read_u32(&buf_hdr->state) & BM_VALID);
+			Assert(pg_atomic_read_u64(&buf_hdr->state) & BM_VALID);
 	}
 #endif
 }
@@ -2078,8 +2078,8 @@ BufferAlloc(SMgrRelation smgr, char relpersistence, ForkNumber forkNum,
 	int			existing_buf_id;
 	Buffer		victim_buffer;
 	BufferDesc *victim_buf_hdr;
-	uint32		victim_buf_state;
-	uint32		set_bits = 0;
+	uint64		victim_buf_state;
+	uint64		set_bits = 0;
 
 	/* Make sure we will have room to remember the buffer pin */
 	ResourceOwnerEnlarge(CurrentResourceOwner);
@@ -2246,7 +2246,7 @@ InvalidateBuffer(BufferDesc *buf)
 	uint32		oldHash;		/* hash value for oldTag */
 	LWLock	   *oldPartitionLock;	/* buffer partition lock for it */
 	uint32		oldFlags;
-	uint32		buf_state;
+	uint64		buf_state;
 
 	/* Save the original buffer tag before dropping the spinlock */
 	oldTag = buf->tag;
@@ -2337,7 +2337,7 @@ retry:
 static bool
 InvalidateVictimBuffer(BufferDesc *buf_hdr)
 {
-	uint32		buf_state;
+	uint64		buf_state;
 	uint32		hash;
 	LWLock	   *partition_lock;
 	BufferTag	tag;
@@ -2397,10 +2397,10 @@ InvalidateVictimBuffer(BufferDesc *buf_hdr)
 
 	LWLockRelease(partition_lock);
 
-	buf_state = pg_atomic_read_u32(&buf_hdr->state);
+	buf_state = pg_atomic_read_u64(&buf_hdr->state);
 	Assert(!(buf_state & (BM_DIRTY | BM_VALID | BM_TAG_VALID)));
 	Assert(BUF_STATE_GET_REFCOUNT(buf_state) > 0);
-	Assert(BUF_STATE_GET_REFCOUNT(pg_atomic_read_u32(&buf_hdr->state)) > 0);
+	Assert(BUF_STATE_GET_REFCOUNT(pg_atomic_read_u64(&buf_hdr->state)) > 0);
 
 	return true;
 }
@@ -2410,7 +2410,7 @@ GetVictimBuffer(BufferAccessStrategy strategy, IOContext io_context)
 {
 	BufferDesc *buf_hdr;
 	Buffer		buf;
-	uint32		buf_state;
+	uint64		buf_state;
 	bool		from_ring;
 
 	/*
@@ -2543,7 +2543,7 @@ again:
 
 	/* a final set of sanity checks */
 #ifdef USE_ASSERT_CHECKING
-	buf_state = pg_atomic_read_u32(&buf_hdr->state);
+	buf_state = pg_atomic_read_u64(&buf_hdr->state);
 
 	Assert(BUF_STATE_GET_REFCOUNT(buf_state) == 1);
 	Assert(!(buf_state & (BM_TAG_VALID | BM_VALID | BM_DIRTY)));
@@ -2834,13 +2834,13 @@ ExtendBufferedRelShared(BufferManagerRelation bmr,
 			 */
 			do
 			{
-				pg_atomic_fetch_and_u32(&existing_hdr->state, ~BM_VALID);
+				pg_atomic_fetch_and_u64(&existing_hdr->state, ~BM_VALID);
 			} while (!StartBufferIO(existing_hdr, true, false));
 		}
 		else
 		{
-			uint32		buf_state;
-			uint32		set_bits = 0;
+			uint64		buf_state;
+			uint64		set_bits = 0;
 
 			buf_state = LockBufHdr(victim_buf_hdr);
 
@@ -3016,7 +3016,7 @@ BufferIsDirty(Buffer buffer)
 		Assert(BufferIsLockedByMeInMode(buffer, BUFFER_LOCK_EXCLUSIVE));
 	}
 
-	return pg_atomic_read_u32(&bufHdr->state) & BM_DIRTY;
+	return pg_atomic_read_u64(&bufHdr->state) & BM_DIRTY;
 }
 
 /*
@@ -3032,8 +3032,8 @@ void
 MarkBufferDirty(Buffer buffer)
 {
 	BufferDesc *bufHdr;
-	uint32		buf_state;
-	uint32		old_buf_state;
+	uint64		buf_state;
+	uint64		old_buf_state;
 
 	if (!BufferIsValid(buffer))
 		elog(ERROR, "bad buffer ID: %d", buffer);
@@ -3053,7 +3053,7 @@ MarkBufferDirty(Buffer buffer)
 	 * NB: We have to wait for the buffer header spinlock to be not held, as
 	 * TerminateBufferIO() relies on the spinlock.
 	 */
-	old_buf_state = pg_atomic_read_u32(&bufHdr->state);
+	old_buf_state = pg_atomic_read_u64(&bufHdr->state);
 	for (;;)
 	{
 		if (old_buf_state & BM_LOCKED)
@@ -3064,7 +3064,7 @@ MarkBufferDirty(Buffer buffer)
 		Assert(BUF_STATE_GET_REFCOUNT(buf_state) > 0);
 		buf_state |= BM_DIRTY | BM_JUST_DIRTIED;
 
-		if (pg_atomic_compare_exchange_u32(&bufHdr->state, &old_buf_state,
+		if (pg_atomic_compare_exchange_u64(&bufHdr->state, &old_buf_state,
 										   buf_state))
 			break;
 	}
@@ -3168,10 +3168,10 @@ PinBuffer(BufferDesc *buf, BufferAccessStrategy strategy,
 
 	if (ref == NULL)
 	{
-		uint32		buf_state;
-		uint32		old_buf_state;
+		uint64		buf_state;
+		uint64		old_buf_state;
 
-		old_buf_state = pg_atomic_read_u32(&buf->state);
+		old_buf_state = pg_atomic_read_u64(&buf->state);
 		for (;;)
 		{
 			if (unlikely(skip_if_not_valid && !(old_buf_state & BM_VALID)))
@@ -3205,7 +3205,7 @@ PinBuffer(BufferDesc *buf, BufferAccessStrategy strategy,
 					buf_state += BUF_USAGECOUNT_ONE;
 			}
 
-			if (pg_atomic_compare_exchange_u32(&buf->state, &old_buf_state,
+			if (pg_atomic_compare_exchange_u64(&buf->state, &old_buf_state,
 											   buf_state))
 			{
 				result = (buf_state & BM_VALID) != 0;
@@ -3232,7 +3232,7 @@ PinBuffer(BufferDesc *buf, BufferAccessStrategy strategy,
 		 * that the buffer page is legitimately non-accessible here.  We
 		 * cannot meddle with that.
 		 */
-		result = (pg_atomic_read_u32(&buf->state) & BM_VALID) != 0;
+		result = (pg_atomic_read_u64(&buf->state) & BM_VALID) != 0;
 
 		Assert(ref->data.refcount > 0);
 		ref->data.refcount++;
@@ -3267,7 +3267,7 @@ PinBuffer(BufferDesc *buf, BufferAccessStrategy strategy,
 static void
 PinBuffer_Locked(BufferDesc *buf)
 {
-	uint32		old_buf_state;
+	uint64		old_buf_state;
 
 	/*
 	 * As explained, We don't expect any preexisting pins. That allows us to
@@ -3279,7 +3279,7 @@ PinBuffer_Locked(BufferDesc *buf)
 	 * Since we hold the buffer spinlock, we can update the buffer state and
 	 * release the lock in one operation.
 	 */
-	old_buf_state = pg_atomic_read_u32(&buf->state);
+	old_buf_state = pg_atomic_read_u64(&buf->state);
 
 	UnlockBufHdrExt(buf, old_buf_state,
 					0, 0, 1);
@@ -3309,7 +3309,7 @@ WakePinCountWaiter(BufferDesc *buf)
 	 * BM_PIN_COUNT_WAITER if it stops waiting for a reason other than this
 	 * backend waking it up.
 	 */
-	uint32		buf_state = LockBufHdr(buf);
+	uint64		buf_state = LockBufHdr(buf);
 
 	if ((buf_state & BM_PIN_COUNT_WAITER) &&
 		BUF_STATE_GET_REFCOUNT(buf_state) == 1)
@@ -3356,7 +3356,7 @@ UnpinBufferNoOwner(BufferDesc *buf)
 	ref->data.refcount--;
 	if (ref->data.refcount == 0)
 	{
-		uint32		old_buf_state;
+		uint64		old_buf_state;
 
 		/*
 		 * Mark buffer non-accessible to Valgrind.
@@ -3374,7 +3374,7 @@ UnpinBufferNoOwner(BufferDesc *buf)
 		Assert(!LWLockHeldByMe(BufferDescriptorGetContentLock(buf)));
 
 		/* decrement the shared reference count */
-		old_buf_state = pg_atomic_fetch_sub_u32(&buf->state, BUF_REFCOUNT_ONE);
+		old_buf_state = pg_atomic_fetch_sub_u64(&buf->state, BUF_REFCOUNT_ONE);
 
 		/* Support LockBufferForCleanup() */
 		if (old_buf_state & BM_PIN_COUNT_WAITER)
@@ -3431,7 +3431,7 @@ TrackNewBufferPin(Buffer buf)
 static void
 BufferSync(int flags)
 {
-	uint32		buf_state;
+	uint64		buf_state;
 	int			buf_id;
 	int			num_to_scan;
 	int			num_spaces;
@@ -3441,7 +3441,7 @@ BufferSync(int flags)
 	Oid			last_tsid;
 	binaryheap *ts_heap;
 	int			i;
-	uint32		mask = BM_DIRTY;
+	uint64		mask = BM_DIRTY;
 	WritebackContext wb_context;
 
 	/*
@@ -3473,7 +3473,7 @@ BufferSync(int flags)
 	for (buf_id = 0; buf_id < NBuffers; buf_id++)
 	{
 		BufferDesc *bufHdr = GetBufferDescriptor(buf_id);
-		uint32		set_bits = 0;
+		uint64		set_bits = 0;
 
 		/*
 		 * Header spinlock is enough to examine BM_DIRTY, see comment in
@@ -3640,7 +3640,7 @@ BufferSync(int flags)
 		 * write the buffer though we didn't need to.  It doesn't seem worth
 		 * guarding against this, though.
 		 */
-		if (pg_atomic_read_u32(&bufHdr->state) & BM_CHECKPOINT_NEEDED)
+		if (pg_atomic_read_u64(&bufHdr->state) & BM_CHECKPOINT_NEEDED)
 		{
 			if (SyncOneBuffer(buf_id, false, &wb_context) & BUF_WRITTEN)
 			{
@@ -4010,7 +4010,7 @@ SyncOneBuffer(int buf_id, bool skip_recently_used, WritebackContext *wb_context)
 {
 	BufferDesc *bufHdr = GetBufferDescriptor(buf_id);
 	int			result = 0;
-	uint32		buf_state;
+	uint64		buf_state;
 	BufferTag	tag;
 
 	/* Make sure we can handle the pin */
@@ -4259,7 +4259,7 @@ DebugPrintBufferRefcount(Buffer buffer)
 	int32		loccount;
 	char	   *result;
 	ProcNumber	backend;
-	uint32		buf_state;
+	uint64		buf_state;
 
 	Assert(BufferIsValid(buffer));
 	if (BufferIsLocal(buffer))
@@ -4276,9 +4276,9 @@ DebugPrintBufferRefcount(Buffer buffer)
 	}
 
 	/* theoretically we should lock the bufhdr here */
-	buf_state = pg_atomic_read_u32(&buf->state);
+	buf_state = pg_atomic_read_u64(&buf->state);
 
-	result = psprintf("[%03d] (rel=%s, blockNum=%u, flags=0x%x, refcount=%u %d)",
+	result = psprintf("[%03d] (rel=%s, blockNum=%u, flags=0x%" PRIx64 ", refcount=%u %d)",
 					  buffer,
 					  relpathbackend(BufTagGetRelFileLocator(&buf->tag), backend,
 									 BufTagGetForkNum(&buf->tag)).str,
@@ -4378,7 +4378,7 @@ FlushBuffer(BufferDesc *buf, SMgrRelation reln, IOObject io_object,
 	instr_time	io_start;
 	Block		bufBlock;
 	char	   *bufToWrite;
-	uint32		buf_state;
+	uint64		buf_state;
 
 	/*
 	 * Try to start an I/O operation.  If StartBufferIO returns false, then
@@ -4576,7 +4576,7 @@ BufferIsPermanent(Buffer buffer)
 	 * not random garbage.
 	 */
 	bufHdr = GetBufferDescriptor(buffer - 1);
-	return (pg_atomic_read_u32(&bufHdr->state) & BM_PERMANENT) != 0;
+	return (pg_atomic_read_u64(&bufHdr->state) & BM_PERMANENT) != 0;
 }
 
 /*
@@ -5039,11 +5039,11 @@ FlushRelationBuffers(Relation rel)
 	{
 		for (i = 0; i < NLocBuffer; i++)
 		{
-			uint32		buf_state;
+			uint64		buf_state;
 
 			bufHdr = GetLocalBufferDescriptor(i);
 			if (BufTagMatchesRelFileLocator(&bufHdr->tag, &rel->rd_locator) &&
-				((buf_state = pg_atomic_read_u32(&bufHdr->state)) &
+				((buf_state = pg_atomic_read_u64(&bufHdr->state)) &
 				 (BM_VALID | BM_DIRTY)) == (BM_VALID | BM_DIRTY))
 			{
 				ErrorContextCallback errcallback;
@@ -5079,7 +5079,7 @@ FlushRelationBuffers(Relation rel)
 
 	for (i = 0; i < NBuffers; i++)
 	{
-		uint32		buf_state;
+		uint64		buf_state;
 
 		bufHdr = GetBufferDescriptor(i);
 
@@ -5151,7 +5151,7 @@ FlushRelationsAllBuffers(SMgrRelation *smgrs, int nrels)
 	{
 		SMgrSortArray *srelent = NULL;
 		BufferDesc *bufHdr = GetBufferDescriptor(i);
-		uint32		buf_state;
+		uint64		buf_state;
 
 		/*
 		 * As in DropRelationBuffers, an unlocked precheck should be safe and
@@ -5400,7 +5400,7 @@ FlushDatabaseBuffers(Oid dbid)
 
 	for (i = 0; i < NBuffers; i++)
 	{
-		uint32		buf_state;
+		uint64		buf_state;
 
 		bufHdr = GetBufferDescriptor(i);
 
@@ -5548,13 +5548,13 @@ MarkBufferDirtyHint(Buffer buffer, bool buffer_std)
 	 * is only intended to be used in cases where failing to write out the
 	 * data would be harmless anyway, it doesn't really matter.
 	 */
-	if ((pg_atomic_read_u32(&bufHdr->state) & (BM_DIRTY | BM_JUST_DIRTIED)) !=
+	if ((pg_atomic_read_u64(&bufHdr->state) & (BM_DIRTY | BM_JUST_DIRTIED)) !=
 		(BM_DIRTY | BM_JUST_DIRTIED))
 	{
 		XLogRecPtr	lsn = InvalidXLogRecPtr;
 		bool		dirtied = false;
 		bool		delayChkptFlags = false;
-		uint32		buf_state;
+		uint64		buf_state;
 
 		/*
 		 * If we need to protect hint bit updates from torn writes, WAL-log a
@@ -5566,7 +5566,7 @@ MarkBufferDirtyHint(Buffer buffer, bool buffer_std)
 		 * when we call XLogInsert() since the value changes dynamically.
 		 */
 		if (XLogHintBitIsNeeded() &&
-			(pg_atomic_read_u32(&bufHdr->state) & BM_PERMANENT))
+			(pg_atomic_read_u64(&bufHdr->state) & BM_PERMANENT))
 		{
 			/*
 			 * If we must not write WAL, due to a relfilelocator-specific
@@ -5666,8 +5666,8 @@ UnlockBuffers(void)
 
 	if (buf)
 	{
-		uint32		buf_state;
-		uint32		unset_bits = 0;
+		uint64		buf_state;
+		uint64		unset_bits = 0;
 
 		buf_state = LockBufHdr(buf);
 
@@ -5798,8 +5798,8 @@ LockBufferForCleanup(Buffer buffer)
 
 	for (;;)
 	{
-		uint32		buf_state;
-		uint32		unset_bits = 0;
+		uint64		buf_state;
+		uint64		unset_bits = 0;
 
 		/* Try to acquire lock */
 		LockBuffer(buffer, BUFFER_LOCK_EXCLUSIVE);
@@ -5947,7 +5947,7 @@ bool
 ConditionalLockBufferForCleanup(Buffer buffer)
 {
 	BufferDesc *bufHdr;
-	uint32		buf_state,
+	uint64		buf_state,
 				refcount;
 
 	Assert(BufferIsValid(buffer));
@@ -6005,7 +6005,7 @@ bool
 IsBufferCleanupOK(Buffer buffer)
 {
 	BufferDesc *bufHdr;
-	uint32		buf_state;
+	uint64		buf_state;
 
 	Assert(BufferIsValid(buffer));
 
@@ -6061,7 +6061,7 @@ WaitIO(BufferDesc *buf)
 	ConditionVariablePrepareToSleep(cv);
 	for (;;)
 	{
-		uint32		buf_state;
+		uint64		buf_state;
 		PgAioWaitRef iow;
 
 		/*
@@ -6135,7 +6135,7 @@ WaitIO(BufferDesc *buf)
 bool
 StartBufferIO(BufferDesc *buf, bool forInput, bool nowait)
 {
-	uint32		buf_state;
+	uint64		buf_state;
 
 	ResourceOwnerEnlarge(CurrentResourceOwner);
 
@@ -6191,11 +6191,11 @@ StartBufferIO(BufferDesc *buf, bool forInput, bool nowait)
  * is being released)
  */
 void
-TerminateBufferIO(BufferDesc *buf, bool clear_dirty, uint32 set_flag_bits,
+TerminateBufferIO(BufferDesc *buf, bool clear_dirty, uint64 set_flag_bits,
 				  bool forget_owner, bool release_aio)
 {
-	uint32		buf_state;
-	uint32		unset_flag_bits = 0;
+	uint64		buf_state;
+	uint64		unset_flag_bits = 0;
 	int			refcount_change = 0;
 
 	buf_state = LockBufHdr(buf);
@@ -6256,7 +6256,7 @@ static void
 AbortBufferIO(Buffer buffer)
 {
 	BufferDesc *buf_hdr = GetBufferDescriptor(buffer - 1);
-	uint32		buf_state;
+	uint64		buf_state;
 
 	buf_state = LockBufHdr(buf_hdr);
 	Assert(buf_state & (BM_IO_IN_PROGRESS | BM_TAG_VALID));
@@ -6350,10 +6350,10 @@ rlocator_comparator(const void *p1, const void *p2)
 /*
  * Lock buffer header - set BM_LOCKED in buffer state.
  */
-uint32
+uint64
 LockBufHdr(BufferDesc *desc)
 {
-	uint32		old_buf_state;
+	uint64		old_buf_state;
 
 	Assert(!BufferIsLocal(BufferDescriptorGetBuffer(desc)));
 
@@ -6362,7 +6362,7 @@ LockBufHdr(BufferDesc *desc)
 	 * infrastructure. The work necessary for that shows up in profiles and is
 	 * rarely necessary.
 	 */
-	old_buf_state = pg_atomic_fetch_or_u32(&desc->state, BM_LOCKED);
+	old_buf_state = pg_atomic_fetch_or_u64(&desc->state, BM_LOCKED);
 
 	if (unlikely(old_buf_state & BM_LOCKED))
 	{
@@ -6373,7 +6373,7 @@ LockBufHdr(BufferDesc *desc)
 		while (true)
 		{
 			/* set BM_LOCKED flag */
-			old_buf_state = pg_atomic_fetch_or_u32(&desc->state, BM_LOCKED);
+			old_buf_state = pg_atomic_fetch_or_u64(&desc->state, BM_LOCKED);
 			/* if it wasn't set before we're OK */
 			if (!(old_buf_state & BM_LOCKED))
 				break;
@@ -6392,20 +6392,20 @@ LockBufHdr(BufferDesc *desc)
  * Obviously the buffer could be locked by the time the value is returned, so
  * this is primarily useful in CAS style loops.
  */
-pg_noinline uint32
+pg_noinline uint64
 WaitBufHdrUnlocked(BufferDesc *buf)
 {
 	SpinDelayStatus delayStatus;
-	uint32		buf_state;
+	uint64		buf_state;
 
 	init_local_spin_delay(&delayStatus);
 
-	buf_state = pg_atomic_read_u32(&buf->state);
+	buf_state = pg_atomic_read_u64(&buf->state);
 
 	while (buf_state & BM_LOCKED)
 	{
 		perform_spin_delay(&delayStatus);
-		buf_state = pg_atomic_read_u32(&buf->state);
+		buf_state = pg_atomic_read_u64(&buf->state);
 	}
 
 	finish_spin_delay(&delayStatus);
@@ -6693,12 +6693,12 @@ ResOwnerPrintBufferPin(Datum res)
 static bool
 EvictUnpinnedBufferInternal(BufferDesc *desc, bool *buffer_flushed)
 {
-	uint32		buf_state;
+	uint64		buf_state;
 	bool		result;
 
 	*buffer_flushed = false;
 
-	buf_state = pg_atomic_read_u32(&(desc->state));
+	buf_state = pg_atomic_read_u64(&(desc->state));
 	Assert(buf_state & BM_LOCKED);
 
 	if ((buf_state & BM_VALID) == 0)
@@ -6792,12 +6792,12 @@ EvictAllUnpinnedBuffers(int32 *buffers_evicted, int32 *buffers_flushed,
 	for (int buf = 1; buf <= NBuffers; buf++)
 	{
 		BufferDesc *desc = GetBufferDescriptor(buf - 1);
-		uint32		buf_state;
+		uint64		buf_state;
 		bool		buffer_flushed;
 
 		CHECK_FOR_INTERRUPTS();
 
-		buf_state = pg_atomic_read_u32(&desc->state);
+		buf_state = pg_atomic_read_u64(&desc->state);
 		if (!(buf_state & BM_VALID))
 			continue;
 
@@ -6844,7 +6844,7 @@ EvictRelUnpinnedBuffers(Relation rel, int32 *buffers_evicted,
 	for (int buf = 1; buf <= NBuffers; buf++)
 	{
 		BufferDesc *desc = GetBufferDescriptor(buf - 1);
-		uint32		buf_state = pg_atomic_read_u32(&(desc->state));
+		uint64		buf_state = pg_atomic_read_u64(&(desc->state));
 		bool		buffer_flushed;
 
 		CHECK_FOR_INTERRUPTS();
@@ -6886,12 +6886,12 @@ static bool
 MarkDirtyUnpinnedBufferInternal(Buffer buf, BufferDesc *desc,
 								bool *buffer_already_dirty)
 {
-	uint32		buf_state;
+	uint64		buf_state;
 	bool		result = false;
 
 	*buffer_already_dirty = false;
 
-	buf_state = pg_atomic_read_u32(&(desc->state));
+	buf_state = pg_atomic_read_u64(&(desc->state));
 	Assert(buf_state & BM_LOCKED);
 
 	if ((buf_state & BM_VALID) == 0)
@@ -6989,7 +6989,7 @@ MarkDirtyRelUnpinnedBuffers(Relation rel,
 	for (int buf = 1; buf <= NBuffers; buf++)
 	{
 		BufferDesc *desc = GetBufferDescriptor(buf - 1);
-		uint32		buf_state = pg_atomic_read_u32(&(desc->state));
+		uint64		buf_state = pg_atomic_read_u64(&(desc->state));
 		bool		buffer_already_dirty;
 
 		CHECK_FOR_INTERRUPTS();
@@ -7043,12 +7043,12 @@ MarkDirtyAllUnpinnedBuffers(int32 *buffers_dirtied,
 	for (int buf = 1; buf <= NBuffers; buf++)
 	{
 		BufferDesc *desc = GetBufferDescriptor(buf - 1);
-		uint32		buf_state;
+		uint64		buf_state;
 		bool		buffer_already_dirty;
 
 		CHECK_FOR_INTERRUPTS();
 
-		buf_state = pg_atomic_read_u32(&desc->state);
+		buf_state = pg_atomic_read_u64(&desc->state);
 		if (!(buf_state & BM_VALID))
 			continue;
 
@@ -7099,7 +7099,7 @@ buffer_stage_common(PgAioHandle *ioh, bool is_write, bool is_temp)
 		BufferDesc *buf_hdr = is_temp ?
 			GetLocalBufferDescriptor(-buffer - 1)
 			: GetBufferDescriptor(buffer - 1);
-		uint32		buf_state;
+		uint64		buf_state;
 
 		/*
 		 * Check that all the buffers are actually ones that could conceivably
@@ -7117,7 +7117,7 @@ buffer_stage_common(PgAioHandle *ioh, bool is_write, bool is_temp)
 		}
 
 		if (is_temp)
-			buf_state = pg_atomic_read_u32(&buf_hdr->state);
+			buf_state = pg_atomic_read_u64(&buf_hdr->state);
 		else
 			buf_state = LockBufHdr(buf_hdr);
 
@@ -7155,7 +7155,7 @@ buffer_stage_common(PgAioHandle *ioh, bool is_write, bool is_temp)
 		if (is_temp)
 		{
 			buf_state += BUF_REFCOUNT_ONE;
-			pg_atomic_unlocked_write_u32(&buf_hdr->state, buf_state);
+			pg_atomic_unlocked_write_u64(&buf_hdr->state, buf_state);
 		}
 		else
 			UnlockBufHdrExt(buf_hdr, buf_state, 0, 0, 1);
@@ -7341,13 +7341,13 @@ buffer_readv_complete_one(PgAioTargetData *td, uint8 buf_off, Buffer buffer,
 		: GetBufferDescriptor(buffer - 1);
 	BufferTag	tag = buf_hdr->tag;
 	char	   *bufdata = BufferGetBlock(buffer);
-	uint32		set_flag_bits;
+	uint64		set_flag_bits;
 	int			piv_flags;
 
 	/* check that the buffer is in the expected state for a read */
 #ifdef USE_ASSERT_CHECKING
 	{
-		uint32		buf_state = pg_atomic_read_u32(&buf_hdr->state);
+		uint64		buf_state = pg_atomic_read_u64(&buf_hdr->state);
 
 		Assert(buf_state & BM_TAG_VALID);
 		Assert(!(buf_state & BM_VALID));
diff --git a/src/backend/storage/buffer/freelist.c b/src/backend/storage/buffer/freelist.c
index 28d952b3534..1d4f19a9afd 100644
--- a/src/backend/storage/buffer/freelist.c
+++ b/src/backend/storage/buffer/freelist.c
@@ -86,7 +86,7 @@ typedef struct BufferAccessStrategyData
 
 /* Prototypes for internal functions */
 static BufferDesc *GetBufferFromRing(BufferAccessStrategy strategy,
-									 uint32 *buf_state);
+									 uint64 *buf_state);
 static void AddBufferToRing(BufferAccessStrategy strategy,
 							BufferDesc *buf);
 
@@ -171,7 +171,7 @@ ClockSweepTick(void)
  *	before returning.
  */
 BufferDesc *
-StrategyGetBuffer(BufferAccessStrategy strategy, uint32 *buf_state, bool *from_ring)
+StrategyGetBuffer(BufferAccessStrategy strategy, uint64 *buf_state, bool *from_ring)
 {
 	BufferDesc *buf;
 	int			bgwprocno;
@@ -230,8 +230,8 @@ StrategyGetBuffer(BufferAccessStrategy strategy, uint32 *buf_state, bool *from_r
 	trycounter = NBuffers;
 	for (;;)
 	{
-		uint32		old_buf_state;
-		uint32		local_buf_state;
+		uint64		old_buf_state;
+		uint64		local_buf_state;
 
 		buf = GetBufferDescriptor(ClockSweepTick());
 
@@ -239,7 +239,7 @@ StrategyGetBuffer(BufferAccessStrategy strategy, uint32 *buf_state, bool *from_r
 		 * Check whether the buffer can be used and pin it if so. Do this
 		 * using a CAS loop, to avoid having to lock the buffer header.
 		 */
-		old_buf_state = pg_atomic_read_u32(&buf->state);
+		old_buf_state = pg_atomic_read_u64(&buf->state);
 		for (;;)
 		{
 			local_buf_state = old_buf_state;
@@ -277,7 +277,7 @@ StrategyGetBuffer(BufferAccessStrategy strategy, uint32 *buf_state, bool *from_r
 			{
 				local_buf_state -= BUF_USAGECOUNT_ONE;
 
-				if (pg_atomic_compare_exchange_u32(&buf->state, &old_buf_state,
+				if (pg_atomic_compare_exchange_u64(&buf->state, &old_buf_state,
 												   local_buf_state))
 				{
 					trycounter = NBuffers;
@@ -289,7 +289,7 @@ StrategyGetBuffer(BufferAccessStrategy strategy, uint32 *buf_state, bool *from_r
 				/* pin the buffer if the CAS succeeds */
 				local_buf_state += BUF_REFCOUNT_ONE;
 
-				if (pg_atomic_compare_exchange_u32(&buf->state, &old_buf_state,
+				if (pg_atomic_compare_exchange_u64(&buf->state, &old_buf_state,
 												   local_buf_state))
 				{
 					/* Found a usable buffer */
@@ -655,12 +655,12 @@ FreeAccessStrategy(BufferAccessStrategy strategy)
  * returning.
  */
 static BufferDesc *
-GetBufferFromRing(BufferAccessStrategy strategy, uint32 *buf_state)
+GetBufferFromRing(BufferAccessStrategy strategy, uint64 *buf_state)
 {
 	BufferDesc *buf;
 	Buffer		bufnum;
-	uint32		old_buf_state;
-	uint32		local_buf_state;	/* to avoid repeated (de-)referencing */
+	uint64		old_buf_state;
+	uint64		local_buf_state;	/* to avoid repeated (de-)referencing */
 
 
 	/* Advance to next ring slot */
@@ -682,7 +682,7 @@ GetBufferFromRing(BufferAccessStrategy strategy, uint32 *buf_state)
 	 * Check whether the buffer can be used and pin it if so. Do this using a
 	 * CAS loop, to avoid having to lock the buffer header.
 	 */
-	old_buf_state = pg_atomic_read_u32(&buf->state);
+	old_buf_state = pg_atomic_read_u64(&buf->state);
 	for (;;)
 	{
 		local_buf_state = old_buf_state;
@@ -710,7 +710,7 @@ GetBufferFromRing(BufferAccessStrategy strategy, uint32 *buf_state)
 		/* pin the buffer if the CAS succeeds */
 		local_buf_state += BUF_REFCOUNT_ONE;
 
-		if (pg_atomic_compare_exchange_u32(&buf->state, &old_buf_state,
+		if (pg_atomic_compare_exchange_u64(&buf->state, &old_buf_state,
 										   local_buf_state))
 		{
 			*buf_state = local_buf_state;
diff --git a/src/backend/storage/buffer/localbuf.c b/src/backend/storage/buffer/localbuf.c
index 15aac7d1c9f..a41a5facd3a 100644
--- a/src/backend/storage/buffer/localbuf.c
+++ b/src/backend/storage/buffer/localbuf.c
@@ -148,7 +148,7 @@ LocalBufferAlloc(SMgrRelation smgr, ForkNumber forkNum, BlockNumber blockNum,
 	}
 	else
 	{
-		uint32		buf_state;
+		uint64		buf_state;
 
 		victim_buffer = GetLocalVictimBuffer();
 		bufid = -victim_buffer - 1;
@@ -165,10 +165,10 @@ LocalBufferAlloc(SMgrRelation smgr, ForkNumber forkNum, BlockNumber blockNum,
 		 */
 		bufHdr->tag = newTag;
 
-		buf_state = pg_atomic_read_u32(&bufHdr->state);
+		buf_state = pg_atomic_read_u64(&bufHdr->state);
 		buf_state &= ~(BUF_FLAG_MASK | BUF_USAGECOUNT_MASK);
 		buf_state |= BM_TAG_VALID | BUF_USAGECOUNT_ONE;
-		pg_atomic_unlocked_write_u32(&bufHdr->state, buf_state);
+		pg_atomic_unlocked_write_u64(&bufHdr->state, buf_state);
 
 		*foundPtr = false;
 	}
@@ -245,12 +245,12 @@ GetLocalVictimBuffer(void)
 
 		if (LocalRefCount[victim_bufid] == 0)
 		{
-			uint32		buf_state = pg_atomic_read_u32(&bufHdr->state);
+			uint64		buf_state = pg_atomic_read_u64(&bufHdr->state);
 
 			if (BUF_STATE_GET_USAGECOUNT(buf_state) > 0)
 			{
 				buf_state -= BUF_USAGECOUNT_ONE;
-				pg_atomic_unlocked_write_u32(&bufHdr->state, buf_state);
+				pg_atomic_unlocked_write_u64(&bufHdr->state, buf_state);
 				trycounter = NLocBuffer;
 			}
 			else if (BUF_STATE_GET_REFCOUNT(buf_state) > 0)
@@ -286,13 +286,13 @@ GetLocalVictimBuffer(void)
 	 * this buffer is not referenced but it might still be dirty. if that's
 	 * the case, write it out before reusing it!
 	 */
-	if (pg_atomic_read_u32(&bufHdr->state) & BM_DIRTY)
+	if (pg_atomic_read_u64(&bufHdr->state) & BM_DIRTY)
 		FlushLocalBuffer(bufHdr, NULL);
 
 	/*
 	 * Remove the victim buffer from the hashtable and mark as invalid.
 	 */
-	if (pg_atomic_read_u32(&bufHdr->state) & BM_TAG_VALID)
+	if (pg_atomic_read_u64(&bufHdr->state) & BM_TAG_VALID)
 	{
 		InvalidateLocalBuffer(bufHdr, false);
 
@@ -417,7 +417,7 @@ ExtendBufferedRelLocal(BufferManagerRelation bmr,
 		if (found)
 		{
 			BufferDesc *existing_hdr;
-			uint32		buf_state;
+			uint64		buf_state;
 
 			UnpinLocalBuffer(BufferDescriptorGetBuffer(victim_buf_hdr));
 
@@ -428,18 +428,18 @@ ExtendBufferedRelLocal(BufferManagerRelation bmr,
 			/*
 			 * Clear the BM_VALID bit, do StartLocalBufferIO() and proceed.
 			 */
-			buf_state = pg_atomic_read_u32(&existing_hdr->state);
+			buf_state = pg_atomic_read_u64(&existing_hdr->state);
 			Assert(buf_state & BM_TAG_VALID);
 			Assert(!(buf_state & BM_DIRTY));
 			buf_state &= ~BM_VALID;
-			pg_atomic_unlocked_write_u32(&existing_hdr->state, buf_state);
+			pg_atomic_unlocked_write_u64(&existing_hdr->state, buf_state);
 
 			/* no need to loop for local buffers */
 			StartLocalBufferIO(existing_hdr, true, false);
 		}
 		else
 		{
-			uint32		buf_state = pg_atomic_read_u32(&victim_buf_hdr->state);
+			uint64		buf_state = pg_atomic_read_u64(&victim_buf_hdr->state);
 
 			Assert(!(buf_state & (BM_VALID | BM_TAG_VALID | BM_DIRTY | BM_JUST_DIRTIED)));
 
@@ -447,7 +447,7 @@ ExtendBufferedRelLocal(BufferManagerRelation bmr,
 
 			buf_state |= BM_TAG_VALID | BUF_USAGECOUNT_ONE;
 
-			pg_atomic_unlocked_write_u32(&victim_buf_hdr->state, buf_state);
+			pg_atomic_unlocked_write_u64(&victim_buf_hdr->state, buf_state);
 
 			hresult->id = victim_buf_id;
 
@@ -467,13 +467,13 @@ ExtendBufferedRelLocal(BufferManagerRelation bmr,
 	{
 		Buffer		buf = buffers[i];
 		BufferDesc *buf_hdr;
-		uint32		buf_state;
+		uint64		buf_state;
 
 		buf_hdr = GetLocalBufferDescriptor(-buf - 1);
 
-		buf_state = pg_atomic_read_u32(&buf_hdr->state);
+		buf_state = pg_atomic_read_u64(&buf_hdr->state);
 		buf_state |= BM_VALID;
-		pg_atomic_unlocked_write_u32(&buf_hdr->state, buf_state);
+		pg_atomic_unlocked_write_u64(&buf_hdr->state, buf_state);
 	}
 
 	*extended_by = extend_by;
@@ -492,7 +492,7 @@ MarkLocalBufferDirty(Buffer buffer)
 {
 	int			bufid;
 	BufferDesc *bufHdr;
-	uint32		buf_state;
+	uint64		buf_state;
 
 	Assert(BufferIsLocal(buffer));
 
@@ -506,14 +506,14 @@ MarkLocalBufferDirty(Buffer buffer)
 
 	bufHdr = GetLocalBufferDescriptor(bufid);
 
-	buf_state = pg_atomic_read_u32(&bufHdr->state);
+	buf_state = pg_atomic_read_u64(&bufHdr->state);
 
 	if (!(buf_state & BM_DIRTY))
 		pgBufferUsage.local_blks_dirtied++;
 
 	buf_state |= BM_DIRTY;
 
-	pg_atomic_unlocked_write_u32(&bufHdr->state, buf_state);
+	pg_atomic_unlocked_write_u64(&bufHdr->state, buf_state);
 }
 
 /*
@@ -522,7 +522,7 @@ MarkLocalBufferDirty(Buffer buffer)
 bool
 StartLocalBufferIO(BufferDesc *bufHdr, bool forInput, bool nowait)
 {
-	uint32		buf_state;
+	uint64		buf_state;
 
 	/*
 	 * With AIO the buffer could have IO in progress, e.g. when there are two
@@ -542,7 +542,7 @@ StartLocalBufferIO(BufferDesc *bufHdr, bool forInput, bool nowait)
 	/* Once we get here, there is definitely no I/O active on this buffer */
 
 	/* Check if someone else already did the I/O */
-	buf_state = pg_atomic_read_u32(&bufHdr->state);
+	buf_state = pg_atomic_read_u64(&bufHdr->state);
 	if (forInput ? (buf_state & BM_VALID) : !(buf_state & BM_DIRTY))
 	{
 		return false;
@@ -559,11 +559,11 @@ StartLocalBufferIO(BufferDesc *bufHdr, bool forInput, bool nowait)
  * Like TerminateBufferIO, but for local buffers
  */
 void
-TerminateLocalBufferIO(BufferDesc *bufHdr, bool clear_dirty, uint32 set_flag_bits,
+TerminateLocalBufferIO(BufferDesc *bufHdr, bool clear_dirty, uint64 set_flag_bits,
 					   bool release_aio)
 {
 	/* Only need to adjust flags */
-	uint32		buf_state = pg_atomic_read_u32(&bufHdr->state);
+	uint64		buf_state = pg_atomic_read_u64(&bufHdr->state);
 
 	/* BM_IO_IN_PROGRESS isn't currently used for local buffers */
 
@@ -582,7 +582,7 @@ TerminateLocalBufferIO(BufferDesc *bufHdr, bool clear_dirty, uint32 set_flag_bit
 	}
 
 	buf_state |= set_flag_bits;
-	pg_atomic_unlocked_write_u32(&bufHdr->state, buf_state);
+	pg_atomic_unlocked_write_u64(&bufHdr->state, buf_state);
 
 	/* local buffers don't track IO using resowners */
 
@@ -606,7 +606,7 @@ InvalidateLocalBuffer(BufferDesc *bufHdr, bool check_unreferenced)
 {
 	Buffer		buffer = BufferDescriptorGetBuffer(bufHdr);
 	int			bufid = -buffer - 1;
-	uint32		buf_state;
+	uint64		buf_state;
 	LocalBufferLookupEnt *hresult;
 
 	/*
@@ -622,7 +622,7 @@ InvalidateLocalBuffer(BufferDesc *bufHdr, bool check_unreferenced)
 		Assert(!pgaio_wref_valid(&bufHdr->io_wref));
 	}
 
-	buf_state = pg_atomic_read_u32(&bufHdr->state);
+	buf_state = pg_atomic_read_u64(&bufHdr->state);
 
 	/*
 	 * We need to test not just LocalRefCount[bufid] but also the BufferDesc
@@ -647,7 +647,7 @@ InvalidateLocalBuffer(BufferDesc *bufHdr, bool check_unreferenced)
 	ClearBufferTag(&bufHdr->tag);
 	buf_state &= ~BUF_FLAG_MASK;
 	buf_state &= ~BUF_USAGECOUNT_MASK;
-	pg_atomic_unlocked_write_u32(&bufHdr->state, buf_state);
+	pg_atomic_unlocked_write_u64(&bufHdr->state, buf_state);
 }
 
 /*
@@ -671,9 +671,9 @@ DropRelationLocalBuffers(RelFileLocator rlocator, ForkNumber *forkNum,
 	for (i = 0; i < NLocBuffer; i++)
 	{
 		BufferDesc *bufHdr = GetLocalBufferDescriptor(i);
-		uint32		buf_state;
+		uint64		buf_state;
 
-		buf_state = pg_atomic_read_u32(&bufHdr->state);
+		buf_state = pg_atomic_read_u64(&bufHdr->state);
 
 		if (!(buf_state & BM_TAG_VALID) ||
 			!BufTagMatchesRelFileLocator(&bufHdr->tag, &rlocator))
@@ -706,9 +706,9 @@ DropRelationAllLocalBuffers(RelFileLocator rlocator)
 	for (i = 0; i < NLocBuffer; i++)
 	{
 		BufferDesc *bufHdr = GetLocalBufferDescriptor(i);
-		uint32		buf_state;
+		uint64		buf_state;
 
-		buf_state = pg_atomic_read_u32(&bufHdr->state);
+		buf_state = pg_atomic_read_u64(&bufHdr->state);
 
 		if ((buf_state & BM_TAG_VALID) &&
 			BufTagMatchesRelFileLocator(&bufHdr->tag, &rlocator))
@@ -804,11 +804,11 @@ InitLocalBuffers(void)
 bool
 PinLocalBuffer(BufferDesc *buf_hdr, bool adjust_usagecount)
 {
-	uint32		buf_state;
+	uint64		buf_state;
 	Buffer		buffer = BufferDescriptorGetBuffer(buf_hdr);
 	int			bufid = -buffer - 1;
 
-	buf_state = pg_atomic_read_u32(&buf_hdr->state);
+	buf_state = pg_atomic_read_u64(&buf_hdr->state);
 
 	if (LocalRefCount[bufid] == 0)
 	{
@@ -819,7 +819,7 @@ PinLocalBuffer(BufferDesc *buf_hdr, bool adjust_usagecount)
 		{
 			buf_state += BUF_USAGECOUNT_ONE;
 		}
-		pg_atomic_unlocked_write_u32(&buf_hdr->state, buf_state);
+		pg_atomic_unlocked_write_u64(&buf_hdr->state, buf_state);
 
 		/*
 		 * See comment in PinBuffer().
@@ -856,14 +856,14 @@ UnpinLocalBufferNoOwner(Buffer buffer)
 	if (--LocalRefCount[buffid] == 0)
 	{
 		BufferDesc *buf_hdr = GetLocalBufferDescriptor(buffid);
-		uint32		buf_state;
+		uint64		buf_state;
 
 		NLocalPinnedBuffers--;
 
-		buf_state = pg_atomic_read_u32(&buf_hdr->state);
+		buf_state = pg_atomic_read_u64(&buf_hdr->state);
 		Assert(BUF_STATE_GET_REFCOUNT(buf_state) > 0);
 		buf_state -= BUF_REFCOUNT_ONE;
-		pg_atomic_unlocked_write_u32(&buf_hdr->state, buf_state);
+		pg_atomic_unlocked_write_u64(&buf_hdr->state, buf_state);
 
 		/* see comment in UnpinBufferNoOwner */
 		VALGRIND_MAKE_MEM_NOACCESS(LocalBufHdrGetBlock(buf_hdr), BLCKSZ);
diff --git a/contrib/pg_buffercache/pg_buffercache_pages.c b/contrib/pg_buffercache/pg_buffercache_pages.c
index 702307a49e2..294caf7a1eb 100644
--- a/contrib/pg_buffercache/pg_buffercache_pages.c
+++ b/contrib/pg_buffercache/pg_buffercache_pages.c
@@ -199,7 +199,7 @@ pg_buffercache_pages(PG_FUNCTION_ARGS)
 		for (i = 0; i < NBuffers; i++)
 		{
 			BufferDesc *bufHdr;
-			uint32		buf_state;
+			uint64		buf_state;
 
 			CHECK_FOR_INTERRUPTS();
 
@@ -615,7 +615,7 @@ pg_buffercache_summary(PG_FUNCTION_ARGS)
 	for (int i = 0; i < NBuffers; i++)
 	{
 		BufferDesc *bufHdr;
-		uint32		buf_state;
+		uint64		buf_state;
 
 		CHECK_FOR_INTERRUPTS();
 
@@ -626,7 +626,7 @@ pg_buffercache_summary(PG_FUNCTION_ARGS)
 		 * noticeably increase the cost of the function.
 		 */
 		bufHdr = GetBufferDescriptor(i);
-		buf_state = pg_atomic_read_u32(&bufHdr->state);
+		buf_state = pg_atomic_read_u64(&bufHdr->state);
 
 		if (buf_state & BM_VALID)
 		{
@@ -676,7 +676,7 @@ pg_buffercache_usage_counts(PG_FUNCTION_ARGS)
 	for (int i = 0; i < NBuffers; i++)
 	{
 		BufferDesc *bufHdr = GetBufferDescriptor(i);
-		uint32		buf_state = pg_atomic_read_u32(&bufHdr->state);
+		uint64		buf_state = pg_atomic_read_u64(&bufHdr->state);
 		int			usage_count;
 
 		CHECK_FOR_INTERRUPTS();
diff --git a/src/test/modules/test_aio/test_aio.c b/src/test/modules/test_aio/test_aio.c
index d7eadeab256..488d98e7e66 100644
--- a/src/test/modules/test_aio/test_aio.c
+++ b/src/test/modules/test_aio/test_aio.c
@@ -308,9 +308,9 @@ create_toy_buffer(Relation rel, BlockNumber blkno)
 {
 	Buffer		buf;
 	BufferDesc *buf_hdr;
-	uint32		buf_state;
+	uint64		buf_state;
 	bool		was_pinned = false;
-	uint32		unset_bits = 0;
+	uint64		unset_bits = 0;
 
 	/* place buffer in shared buffers without erroring out */
 	buf = ReadBufferExtended(rel, MAIN_FORKNUM, blkno, RBM_ZERO_AND_LOCK, NULL);
@@ -319,7 +319,7 @@ create_toy_buffer(Relation rel, BlockNumber blkno)
 	if (RelationUsesLocalBuffers(rel))
 	{
 		buf_hdr = GetLocalBufferDescriptor(-buf - 1);
-		buf_state = pg_atomic_read_u32(&buf_hdr->state);
+		buf_state = pg_atomic_read_u64(&buf_hdr->state);
 	}
 	else
 	{
@@ -340,7 +340,7 @@ create_toy_buffer(Relation rel, BlockNumber blkno)
 	if (RelationUsesLocalBuffers(rel))
 	{
 		buf_state &= ~unset_bits;
-		pg_atomic_unlocked_write_u32(&buf_hdr->state, buf_state);
+		pg_atomic_unlocked_write_u64(&buf_hdr->state, buf_state);
 	}
 	else
 	{
@@ -489,7 +489,7 @@ invalidate_rel_block(PG_FUNCTION_ARGS)
 
 			LockBuffer(buf, BUFFER_LOCK_EXCLUSIVE);
 
-			if (pg_atomic_read_u32(&buf_hdr->state) & BM_DIRTY)
+			if (pg_atomic_read_u64(&buf_hdr->state) & BM_DIRTY)
 			{
 				if (BufferIsLocal(buf))
 					FlushLocalBuffer(buf_hdr, NULL);
@@ -572,7 +572,7 @@ buffer_call_terminate_io(PG_FUNCTION_ARGS)
 	bool		io_error = PG_GETARG_BOOL(3);
 	bool		release_aio = PG_GETARG_BOOL(4);
 	bool		clear_dirty = false;
-	uint32		set_flag_bits = 0;
+	uint64		set_flag_bits = 0;
 
 	if (io_error)
 		set_flag_bits |= BM_IO_ERROR;
-- 
2.48.1.76.g4e746b1a31.dirty


--kad4mm4awdo7v2ki
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
	filename="v7-0012-bufmgr-Implement-buffer-content-locks-independent.patch"



^ permalink  raw  reply  [nested|flat] 129+ messages in thread

* [PATCH v8 06/10] bufmgr: Change BufferDesc.state to be a 64bit atomic
@ 2025-12-18 23:28  Andres Freund <andres@anarazel.de>
  0 siblings, 0 replies; 129+ messages in thread

From: Andres Freund @ 2025-12-18 23:28 UTC (permalink / raw)

This is motivated by wanting to merge buffer content locks into
BufferDesc.state in a future commit, rather than having a separate lwlock (see
commit c75ebc657ff more details). As this change is rather mechanical, it
seems to make sense to split it out into a separate commit, for easier review.

Reviewed-by: Melanie Plageman <melanieplageman@gmail.com>
Discussion: https://postgr.es/m/fvfmkr5kk4nyex56ejgxj3uzi63isfxovp2biecb4bspbjrze7@az2pljabhnff
---
 src/include/storage/buf_internals.h           |  88 +++++----
 src/include/storage/procnumber.h              |  14 +-
 src/backend/storage/buffer/buf_init.c         |   2 +-
 src/backend/storage/buffer/bufmgr.c           | 170 +++++++++---------
 src/backend/storage/buffer/freelist.c         |  24 +--
 src/backend/storage/buffer/localbuf.c         |  72 ++++----
 contrib/pg_buffercache/pg_buffercache_pages.c |   8 +-
 src/test/modules/test_aio/test_aio.c          |  12 +-
 8 files changed, 205 insertions(+), 185 deletions(-)

diff --git a/src/include/storage/buf_internals.h b/src/include/storage/buf_internals.h
index 5400c56a965..28519ad2813 100644
--- a/src/include/storage/buf_internals.h
+++ b/src/include/storage/buf_internals.h
@@ -30,7 +30,7 @@
 #include "utils/resowner.h"
 
 /*
- * Buffer state is a single 32-bit variable where following data is combined.
+ * Buffer state is a single 64-bit variable where following data is combined.
  *
  * - 18 bits refcount
  * - 4 bits usage count
@@ -39,6 +39,9 @@
  * Combining these values allows to perform some operations without locking
  * the buffer header, by modifying them together with a CAS loop.
  *
+ * NB: A future commit will use a significant portion of the remaining bits to
+ * implement buffer locking as part of the state variable.
+ *
  * The definition of buffer state components is below.
  */
 #define BUF_REFCOUNT_BITS 18
@@ -49,15 +52,21 @@ StaticAssertDecl(BUF_REFCOUNT_BITS + BUF_USAGECOUNT_BITS + BUF_FLAG_BITS == 32,
 				 "parts of buffer state space need to equal 32");
 
 #define BUF_REFCOUNT_ONE 1
-#define BUF_REFCOUNT_MASK ((1U << BUF_REFCOUNT_BITS) - 1)
-#define BUF_USAGECOUNT_MASK (((1U << BUF_USAGECOUNT_BITS) - 1) << (BUF_REFCOUNT_BITS))
-#define BUF_USAGECOUNT_ONE (1U << BUF_REFCOUNT_BITS)
+#define BUF_REFCOUNT_MASK \
+	((UINT64CONST(1) << BUF_REFCOUNT_BITS) - 1)
+#define BUF_USAGECOUNT_MASK \
+	(((UINT64CONST(1) << BUF_USAGECOUNT_BITS) - 1) << (BUF_REFCOUNT_BITS))
+#define BUF_USAGECOUNT_ONE \
+	(UINT64CONST(1) << BUF_REFCOUNT_BITS)
 #define BUF_USAGECOUNT_SHIFT BUF_REFCOUNT_BITS
-#define BUF_FLAG_MASK (((1U << BUF_FLAG_BITS) - 1) << (BUF_REFCOUNT_BITS + BUF_USAGECOUNT_BITS))
+#define BUF_FLAG_MASK \
+	(((UINT64CONST(1) << BUF_FLAG_BITS) - 1) << (BUF_REFCOUNT_BITS + BUF_USAGECOUNT_BITS))
 
 /* Get refcount and usagecount from buffer state */
-#define BUF_STATE_GET_REFCOUNT(state) ((state) & BUF_REFCOUNT_MASK)
-#define BUF_STATE_GET_USAGECOUNT(state) (((state) & BUF_USAGECOUNT_MASK) >> BUF_USAGECOUNT_SHIFT)
+#define BUF_STATE_GET_REFCOUNT(state) \
+	((uint32)((state) & BUF_REFCOUNT_MASK))
+#define BUF_STATE_GET_USAGECOUNT(state) \
+	((uint32)(((state) & BUF_USAGECOUNT_MASK) >> BUF_USAGECOUNT_SHIFT))
 
 /*
  * Flags for buffer descriptors
@@ -65,17 +74,28 @@ StaticAssertDecl(BUF_REFCOUNT_BITS + BUF_USAGECOUNT_BITS + BUF_FLAG_BITS == 32,
  * Note: BM_TAG_VALID essentially means that there is a buffer hashtable
  * entry associated with the buffer's tag.
  */
-#define BM_LOCKED				(1U << 22)	/* buffer header is locked */
-#define BM_DIRTY				(1U << 23)	/* data needs writing */
-#define BM_VALID				(1U << 24)	/* data is valid */
-#define BM_TAG_VALID			(1U << 25)	/* tag is assigned */
-#define BM_IO_IN_PROGRESS		(1U << 26)	/* read or write in progress */
-#define BM_IO_ERROR				(1U << 27)	/* previous I/O failed */
-#define BM_JUST_DIRTIED			(1U << 28)	/* dirtied since write started */
-#define BM_PIN_COUNT_WAITER		(1U << 29)	/* have waiter for sole pin */
-#define BM_CHECKPOINT_NEEDED	(1U << 30)	/* must write for checkpoint */
-#define BM_PERMANENT			(1U << 31)	/* permanent buffer (not unlogged,
-											 * or init fork) */
+
+/* buffer header is locked */
+#define BM_LOCKED				(UINT64CONST(1) << 22)
+/* data needs writing */
+#define BM_DIRTY				(UINT64CONST(1) << 23)
+/* data is valid */
+#define BM_VALID				(UINT64CONST(1) << 24)
+/* tag is assigned */
+#define BM_TAG_VALID			(UINT64CONST(1) << 25)
+/* read or write in progress */
+#define BM_IO_IN_PROGRESS		(UINT64CONST(1) << 26)
+/* previous I/O failed */
+#define BM_IO_ERROR				(UINT64CONST(1) << 27)
+/* dirtied since write started */
+#define BM_JUST_DIRTIED			(UINT64CONST(1) << 28)
+/* have waiter for sole pin */
+#define BM_PIN_COUNT_WAITER		(UINT64CONST(1) << 29)
+/* must write for checkpoint */
+#define BM_CHECKPOINT_NEEDED	(UINT64CONST(1) << 30)
+/* permanent buffer (not unlogged, or init fork) */
+#define BM_PERMANENT			(UINT64CONST(1) << 31)
+
 /*
  * The maximum allowed value of usage_count represents a tradeoff between
  * accuracy and speed of the clock-sweep buffer management algorithm.  A
@@ -86,7 +106,7 @@ StaticAssertDecl(BUF_REFCOUNT_BITS + BUF_USAGECOUNT_BITS + BUF_FLAG_BITS == 32,
  */
 #define BM_MAX_USAGE_COUNT	5
 
-StaticAssertDecl(BM_MAX_USAGE_COUNT < (1 << BUF_USAGECOUNT_BITS),
+StaticAssertDecl(BM_MAX_USAGE_COUNT < (UINT64CONST(1) << BUF_USAGECOUNT_BITS),
 				 "BM_MAX_USAGE_COUNT doesn't fit in BUF_USAGECOUNT_BITS bits");
 StaticAssertDecl(MAX_BACKENDS_BITS <= BUF_REFCOUNT_BITS,
 				 "MAX_BACKENDS_BITS needs to be <= BUF_REFCOUNT_BITS");
@@ -251,8 +271,8 @@ BufMappingPartitionLockByIndex(uint32 index)
  * We use this same struct for local buffer headers, but the locks are not
  * used and not all of the flag bits are useful either. To avoid unnecessary
  * overhead, manipulations of the state field should be done without actual
- * atomic operations (i.e. only pg_atomic_read_u32() and
- * pg_atomic_unlocked_write_u32()).
+ * atomic operations (i.e. only pg_atomic_read_u64() and
+ * pg_atomic_unlocked_write_u64()).
  *
  * Be careful to avoid increasing the size of the struct when adding or
  * reordering members.  Keeping it below 64 bytes (the most common CPU
@@ -280,7 +300,7 @@ typedef struct BufferDesc
 	 * State of the buffer, containing flags, refcount and usagecount. See
 	 * BUF_* and BM_* defines at the top of this file.
 	 */
-	pg_atomic_uint32 state;
+	pg_atomic_uint64 state;
 
 	/*
 	 * Backend of pin-count waiter. The buffer header spinlock needs to be
@@ -386,7 +406,7 @@ BufferDescriptorGetContentLock(const BufferDesc *bdesc)
  * Functions for acquiring/releasing a shared buffer header's spinlock.  Do
  * not apply these to local buffers!
  */
-extern uint32 LockBufHdr(BufferDesc *desc);
+extern uint64 LockBufHdr(BufferDesc *desc);
 
 /*
  * Unlock the buffer header.
@@ -397,9 +417,9 @@ extern uint32 LockBufHdr(BufferDesc *desc);
 static inline void
 UnlockBufHdr(BufferDesc *desc)
 {
-	Assert(pg_atomic_read_u32(&desc->state) & BM_LOCKED);
+	Assert(pg_atomic_read_u64(&desc->state) & BM_LOCKED);
 
-	pg_atomic_fetch_sub_u32(&desc->state, BM_LOCKED);
+	pg_atomic_fetch_sub_u64(&desc->state, BM_LOCKED);
 }
 
 /*
@@ -410,14 +430,14 @@ UnlockBufHdr(BufferDesc *desc)
  * Note that this approach would not work for usagecount, since we need to cap
  * the usagecount at BM_MAX_USAGE_COUNT.
  */
-static inline uint32
-UnlockBufHdrExt(BufferDesc *desc, uint32 old_buf_state,
-				uint32 set_bits, uint32 unset_bits,
+static inline uint64
+UnlockBufHdrExt(BufferDesc *desc, uint64 old_buf_state,
+				uint64 set_bits, uint64 unset_bits,
 				int refcount_change)
 {
 	for (;;)
 	{
-		uint32		buf_state = old_buf_state;
+		uint64		buf_state = old_buf_state;
 
 		Assert(buf_state & BM_LOCKED);
 
@@ -428,7 +448,7 @@ UnlockBufHdrExt(BufferDesc *desc, uint32 old_buf_state,
 		if (refcount_change != 0)
 			buf_state += BUF_REFCOUNT_ONE * refcount_change;
 
-		if (pg_atomic_compare_exchange_u32(&desc->state, &old_buf_state,
+		if (pg_atomic_compare_exchange_u64(&desc->state, &old_buf_state,
 										   buf_state))
 		{
 			return old_buf_state;
@@ -436,7 +456,7 @@ UnlockBufHdrExt(BufferDesc *desc, uint32 old_buf_state,
 	}
 }
 
-extern uint32 WaitBufHdrUnlocked(BufferDesc *buf);
+extern uint64 WaitBufHdrUnlocked(BufferDesc *buf);
 
 /* in bufmgr.c */
 
@@ -496,14 +516,14 @@ extern void TrackNewBufferPin(Buffer buf);
 
 /* solely to make it easier to write tests */
 extern bool StartBufferIO(BufferDesc *buf, bool forInput, bool nowait);
-extern void TerminateBufferIO(BufferDesc *buf, bool clear_dirty, uint32 set_flag_bits,
+extern void TerminateBufferIO(BufferDesc *buf, bool clear_dirty, uint64 set_flag_bits,
 							  bool forget_owner, bool release_aio);
 
 
 /* freelist.c */
 extern IOContext IOContextForStrategy(BufferAccessStrategy strategy);
 extern BufferDesc *StrategyGetBuffer(BufferAccessStrategy strategy,
-									 uint32 *buf_state, bool *from_ring);
+									 uint64 *buf_state, bool *from_ring);
 extern bool StrategyRejectBuffer(BufferAccessStrategy strategy,
 								 BufferDesc *buf, bool from_ring);
 
@@ -539,7 +559,7 @@ extern BlockNumber ExtendBufferedRelLocal(BufferManagerRelation bmr,
 										  uint32 *extended_by);
 extern void MarkLocalBufferDirty(Buffer buffer);
 extern void TerminateLocalBufferIO(BufferDesc *bufHdr, bool clear_dirty,
-								   uint32 set_flag_bits, bool release_aio);
+								   uint64 set_flag_bits, bool release_aio);
 extern bool StartLocalBufferIO(BufferDesc *bufHdr, bool forInput, bool nowait);
 extern void FlushLocalBuffer(BufferDesc *bufHdr, SMgrRelation reln);
 extern void InvalidateLocalBuffer(BufferDesc *bufHdr, bool check_unreferenced);
diff --git a/src/include/storage/procnumber.h b/src/include/storage/procnumber.h
index 2ddaaf0c646..6baac7c77f1 100644
--- a/src/include/storage/procnumber.h
+++ b/src/include/storage/procnumber.h
@@ -27,13 +27,13 @@ typedef int ProcNumber;
 
 /*
  * Note: MAX_BACKENDS_BITS is 18 as that is the space available for buffer
- * refcounts in buf_internals.h.  This limitation could be lifted by using a
- * 64bit state; but it's unlikely to be worthwhile as 2^18-1 backends exceed
- * currently realistic configurations. Even if that limitation were removed,
- * we still could not a) exceed 2^23-1 because inval.c stores the ProcNumber
- * as a 3-byte signed integer, b) INT_MAX/4 because some places compute
- * 4*MaxBackends without any overflow check.  We check that the configured
- * number of backends does not exceed MAX_BACKENDS in InitializeMaxBackends().
+ * refcounts in buf_internals.h.  This limitation could be lifted, but it's
+ * unlikely to be worthwhile as 2^18-1 backends exceed currently realistic
+ * configurations. Even if that limitation were removed, we still could not a)
+ * exceed 2^23-1 because inval.c stores the ProcNumber as a 3-byte signed
+ * integer, b) INT_MAX/4 because some places compute 4*MaxBackends without any
+ * overflow check.  We check that the configured number of backends does not
+ * exceed MAX_BACKENDS in InitializeMaxBackends().
  */
 #define MAX_BACKENDS_BITS		18
 #define MAX_BACKENDS			((1U << MAX_BACKENDS_BITS)-1)
diff --git a/src/backend/storage/buffer/buf_init.c b/src/backend/storage/buffer/buf_init.c
index 6fd3a6bbac5..25f71191ec3 100644
--- a/src/backend/storage/buffer/buf_init.c
+++ b/src/backend/storage/buffer/buf_init.c
@@ -121,7 +121,7 @@ BufferManagerShmemInit(void)
 
 			ClearBufferTag(&buf->tag);
 
-			pg_atomic_init_u32(&buf->state, 0);
+			pg_atomic_init_u64(&buf->state, 0);
 			buf->wait_backend_pgprocno = INVALID_PROC_NUMBER;
 
 			buf->buf_id = i;
diff --git a/src/backend/storage/buffer/bufmgr.c b/src/backend/storage/buffer/bufmgr.c
index eb55102b0d7..03d99d294d5 100644
--- a/src/backend/storage/buffer/bufmgr.c
+++ b/src/backend/storage/buffer/bufmgr.c
@@ -780,7 +780,7 @@ ReadRecentBuffer(RelFileLocator rlocator, ForkNumber forkNum, BlockNumber blockN
 {
 	BufferDesc *bufHdr;
 	BufferTag	tag;
-	uint32		buf_state;
+	uint64		buf_state;
 
 	Assert(BufferIsValid(recent_buffer));
 
@@ -793,7 +793,7 @@ ReadRecentBuffer(RelFileLocator rlocator, ForkNumber forkNum, BlockNumber blockN
 		int			b = -recent_buffer - 1;
 
 		bufHdr = GetLocalBufferDescriptor(b);
-		buf_state = pg_atomic_read_u32(&bufHdr->state);
+		buf_state = pg_atomic_read_u64(&bufHdr->state);
 
 		/* Is it still valid and holding the right tag? */
 		if ((buf_state & BM_VALID) && BufferTagsEqual(&tag, &bufHdr->tag))
@@ -1386,8 +1386,8 @@ StartReadBuffersImpl(ReadBuffersOperation *operation,
 				bufHdr = GetLocalBufferDescriptor(-buffers[i] - 1);
 			else
 				bufHdr = GetBufferDescriptor(buffers[i] - 1);
-			Assert(pg_atomic_read_u32(&bufHdr->state) & BM_TAG_VALID);
-			found = pg_atomic_read_u32(&bufHdr->state) & BM_VALID;
+			Assert(pg_atomic_read_u64(&bufHdr->state) & BM_TAG_VALID);
+			found = pg_atomic_read_u64(&bufHdr->state) & BM_VALID;
 		}
 		else
 		{
@@ -1613,10 +1613,10 @@ CheckReadBuffersOperation(ReadBuffersOperation *operation, bool is_complete)
 			GetBufferDescriptor(buffer - 1);
 
 		Assert(BufferGetBlockNumber(buffer) == operation->blocknum + i);
-		Assert(pg_atomic_read_u32(&buf_hdr->state) & BM_TAG_VALID);
+		Assert(pg_atomic_read_u64(&buf_hdr->state) & BM_TAG_VALID);
 
 		if (i < operation->nblocks_done)
-			Assert(pg_atomic_read_u32(&buf_hdr->state) & BM_VALID);
+			Assert(pg_atomic_read_u64(&buf_hdr->state) & BM_VALID);
 	}
 #endif
 }
@@ -2083,8 +2083,8 @@ BufferAlloc(SMgrRelation smgr, char relpersistence, ForkNumber forkNum,
 	int			existing_buf_id;
 	Buffer		victim_buffer;
 	BufferDesc *victim_buf_hdr;
-	uint32		victim_buf_state;
-	uint32		set_bits = 0;
+	uint64		victim_buf_state;
+	uint64		set_bits = 0;
 
 	/* Make sure we will have room to remember the buffer pin */
 	ResourceOwnerEnlarge(CurrentResourceOwner);
@@ -2251,7 +2251,7 @@ InvalidateBuffer(BufferDesc *buf)
 	uint32		oldHash;		/* hash value for oldTag */
 	LWLock	   *oldPartitionLock;	/* buffer partition lock for it */
 	uint32		oldFlags;
-	uint32		buf_state;
+	uint64		buf_state;
 
 	/* Save the original buffer tag before dropping the spinlock */
 	oldTag = buf->tag;
@@ -2342,7 +2342,7 @@ retry:
 static bool
 InvalidateVictimBuffer(BufferDesc *buf_hdr)
 {
-	uint32		buf_state;
+	uint64		buf_state;
 	uint32		hash;
 	LWLock	   *partition_lock;
 	BufferTag	tag;
@@ -2402,10 +2402,10 @@ InvalidateVictimBuffer(BufferDesc *buf_hdr)
 
 	LWLockRelease(partition_lock);
 
-	buf_state = pg_atomic_read_u32(&buf_hdr->state);
+	buf_state = pg_atomic_read_u64(&buf_hdr->state);
 	Assert(!(buf_state & (BM_DIRTY | BM_VALID | BM_TAG_VALID)));
 	Assert(BUF_STATE_GET_REFCOUNT(buf_state) > 0);
-	Assert(BUF_STATE_GET_REFCOUNT(pg_atomic_read_u32(&buf_hdr->state)) > 0);
+	Assert(BUF_STATE_GET_REFCOUNT(pg_atomic_read_u64(&buf_hdr->state)) > 0);
 
 	return true;
 }
@@ -2415,7 +2415,7 @@ GetVictimBuffer(BufferAccessStrategy strategy, IOContext io_context)
 {
 	BufferDesc *buf_hdr;
 	Buffer		buf;
-	uint32		buf_state;
+	uint64		buf_state;
 	bool		from_ring;
 
 	/*
@@ -2548,7 +2548,7 @@ again:
 
 	/* a final set of sanity checks */
 #ifdef USE_ASSERT_CHECKING
-	buf_state = pg_atomic_read_u32(&buf_hdr->state);
+	buf_state = pg_atomic_read_u64(&buf_hdr->state);
 
 	Assert(BUF_STATE_GET_REFCOUNT(buf_state) == 1);
 	Assert(!(buf_state & (BM_TAG_VALID | BM_VALID | BM_DIRTY)));
@@ -2839,13 +2839,13 @@ ExtendBufferedRelShared(BufferManagerRelation bmr,
 			 */
 			do
 			{
-				pg_atomic_fetch_and_u32(&existing_hdr->state, ~BM_VALID);
+				pg_atomic_fetch_and_u64(&existing_hdr->state, ~BM_VALID);
 			} while (!StartBufferIO(existing_hdr, true, false));
 		}
 		else
 		{
-			uint32		buf_state;
-			uint32		set_bits = 0;
+			uint64		buf_state;
+			uint64		set_bits = 0;
 
 			buf_state = LockBufHdr(victim_buf_hdr);
 
@@ -3021,7 +3021,7 @@ BufferIsDirty(Buffer buffer)
 		Assert(BufferIsLockedByMeInMode(buffer, BUFFER_LOCK_EXCLUSIVE));
 	}
 
-	return pg_atomic_read_u32(&bufHdr->state) & BM_DIRTY;
+	return pg_atomic_read_u64(&bufHdr->state) & BM_DIRTY;
 }
 
 /*
@@ -3037,8 +3037,8 @@ void
 MarkBufferDirty(Buffer buffer)
 {
 	BufferDesc *bufHdr;
-	uint32		buf_state;
-	uint32		old_buf_state;
+	uint64		buf_state;
+	uint64		old_buf_state;
 
 	if (!BufferIsValid(buffer))
 		elog(ERROR, "bad buffer ID: %d", buffer);
@@ -3058,7 +3058,7 @@ MarkBufferDirty(Buffer buffer)
 	 * NB: We have to wait for the buffer header spinlock to be not held, as
 	 * TerminateBufferIO() relies on the spinlock.
 	 */
-	old_buf_state = pg_atomic_read_u32(&bufHdr->state);
+	old_buf_state = pg_atomic_read_u64(&bufHdr->state);
 	for (;;)
 	{
 		if (old_buf_state & BM_LOCKED)
@@ -3069,7 +3069,7 @@ MarkBufferDirty(Buffer buffer)
 		Assert(BUF_STATE_GET_REFCOUNT(buf_state) > 0);
 		buf_state |= BM_DIRTY | BM_JUST_DIRTIED;
 
-		if (pg_atomic_compare_exchange_u32(&bufHdr->state, &old_buf_state,
+		if (pg_atomic_compare_exchange_u64(&bufHdr->state, &old_buf_state,
 										   buf_state))
 			break;
 	}
@@ -3173,10 +3173,10 @@ PinBuffer(BufferDesc *buf, BufferAccessStrategy strategy,
 
 	if (ref == NULL)
 	{
-		uint32		buf_state;
-		uint32		old_buf_state;
+		uint64		buf_state;
+		uint64		old_buf_state;
 
-		old_buf_state = pg_atomic_read_u32(&buf->state);
+		old_buf_state = pg_atomic_read_u64(&buf->state);
 		for (;;)
 		{
 			if (unlikely(skip_if_not_valid && !(old_buf_state & BM_VALID)))
@@ -3210,7 +3210,7 @@ PinBuffer(BufferDesc *buf, BufferAccessStrategy strategy,
 					buf_state += BUF_USAGECOUNT_ONE;
 			}
 
-			if (pg_atomic_compare_exchange_u32(&buf->state, &old_buf_state,
+			if (pg_atomic_compare_exchange_u64(&buf->state, &old_buf_state,
 											   buf_state))
 			{
 				result = (buf_state & BM_VALID) != 0;
@@ -3237,7 +3237,7 @@ PinBuffer(BufferDesc *buf, BufferAccessStrategy strategy,
 		 * that the buffer page is legitimately non-accessible here.  We
 		 * cannot meddle with that.
 		 */
-		result = (pg_atomic_read_u32(&buf->state) & BM_VALID) != 0;
+		result = (pg_atomic_read_u64(&buf->state) & BM_VALID) != 0;
 
 		Assert(ref->data.refcount > 0);
 		ref->data.refcount++;
@@ -3272,7 +3272,7 @@ PinBuffer(BufferDesc *buf, BufferAccessStrategy strategy,
 static void
 PinBuffer_Locked(BufferDesc *buf)
 {
-	uint32		old_buf_state;
+	uint64		old_buf_state;
 
 	/*
 	 * As explained, We don't expect any preexisting pins. That allows us to
@@ -3284,7 +3284,7 @@ PinBuffer_Locked(BufferDesc *buf)
 	 * Since we hold the buffer spinlock, we can update the buffer state and
 	 * release the lock in one operation.
 	 */
-	old_buf_state = pg_atomic_read_u32(&buf->state);
+	old_buf_state = pg_atomic_read_u64(&buf->state);
 
 	UnlockBufHdrExt(buf, old_buf_state,
 					0, 0, 1);
@@ -3314,7 +3314,7 @@ WakePinCountWaiter(BufferDesc *buf)
 	 * BM_PIN_COUNT_WAITER if it stops waiting for a reason other than this
 	 * backend waking it up.
 	 */
-	uint32		buf_state = LockBufHdr(buf);
+	uint64		buf_state = LockBufHdr(buf);
 
 	if ((buf_state & BM_PIN_COUNT_WAITER) &&
 		BUF_STATE_GET_REFCOUNT(buf_state) == 1)
@@ -3361,7 +3361,7 @@ UnpinBufferNoOwner(BufferDesc *buf)
 	ref->data.refcount--;
 	if (ref->data.refcount == 0)
 	{
-		uint32		old_buf_state;
+		uint64		old_buf_state;
 
 		/*
 		 * Mark buffer non-accessible to Valgrind.
@@ -3379,7 +3379,7 @@ UnpinBufferNoOwner(BufferDesc *buf)
 		Assert(!LWLockHeldByMe(BufferDescriptorGetContentLock(buf)));
 
 		/* decrement the shared reference count */
-		old_buf_state = pg_atomic_fetch_sub_u32(&buf->state, BUF_REFCOUNT_ONE);
+		old_buf_state = pg_atomic_fetch_sub_u64(&buf->state, BUF_REFCOUNT_ONE);
 
 		/* Support LockBufferForCleanup() */
 		if (old_buf_state & BM_PIN_COUNT_WAITER)
@@ -3436,7 +3436,7 @@ TrackNewBufferPin(Buffer buf)
 static void
 BufferSync(int flags)
 {
-	uint32		buf_state;
+	uint64		buf_state;
 	int			buf_id;
 	int			num_to_scan;
 	int			num_spaces;
@@ -3446,7 +3446,7 @@ BufferSync(int flags)
 	Oid			last_tsid;
 	binaryheap *ts_heap;
 	int			i;
-	uint32		mask = BM_DIRTY;
+	uint64		mask = BM_DIRTY;
 	WritebackContext wb_context;
 
 	/*
@@ -3478,7 +3478,7 @@ BufferSync(int flags)
 	for (buf_id = 0; buf_id < NBuffers; buf_id++)
 	{
 		BufferDesc *bufHdr = GetBufferDescriptor(buf_id);
-		uint32		set_bits = 0;
+		uint64		set_bits = 0;
 
 		/*
 		 * Header spinlock is enough to examine BM_DIRTY, see comment in
@@ -3645,7 +3645,7 @@ BufferSync(int flags)
 		 * write the buffer though we didn't need to.  It doesn't seem worth
 		 * guarding against this, though.
 		 */
-		if (pg_atomic_read_u32(&bufHdr->state) & BM_CHECKPOINT_NEEDED)
+		if (pg_atomic_read_u64(&bufHdr->state) & BM_CHECKPOINT_NEEDED)
 		{
 			if (SyncOneBuffer(buf_id, false, &wb_context) & BUF_WRITTEN)
 			{
@@ -4015,7 +4015,7 @@ SyncOneBuffer(int buf_id, bool skip_recently_used, WritebackContext *wb_context)
 {
 	BufferDesc *bufHdr = GetBufferDescriptor(buf_id);
 	int			result = 0;
-	uint32		buf_state;
+	uint64		buf_state;
 	BufferTag	tag;
 
 	/* Make sure we can handle the pin */
@@ -4264,7 +4264,7 @@ DebugPrintBufferRefcount(Buffer buffer)
 	int32		loccount;
 	char	   *result;
 	ProcNumber	backend;
-	uint32		buf_state;
+	uint64		buf_state;
 
 	Assert(BufferIsValid(buffer));
 	if (BufferIsLocal(buffer))
@@ -4281,9 +4281,9 @@ DebugPrintBufferRefcount(Buffer buffer)
 	}
 
 	/* theoretically we should lock the bufhdr here */
-	buf_state = pg_atomic_read_u32(&buf->state);
+	buf_state = pg_atomic_read_u64(&buf->state);
 
-	result = psprintf("[%03d] (rel=%s, blockNum=%u, flags=0x%x, refcount=%u %d)",
+	result = psprintf("[%03d] (rel=%s, blockNum=%u, flags=0x%" PRIx64 ", refcount=%u %d)",
 					  buffer,
 					  relpathbackend(BufTagGetRelFileLocator(&buf->tag), backend,
 									 BufTagGetForkNum(&buf->tag)).str,
@@ -4383,7 +4383,7 @@ FlushBuffer(BufferDesc *buf, SMgrRelation reln, IOObject io_object,
 	instr_time	io_start;
 	Block		bufBlock;
 	char	   *bufToWrite;
-	uint32		buf_state;
+	uint64		buf_state;
 
 	/*
 	 * Try to start an I/O operation.  If StartBufferIO returns false, then
@@ -4581,7 +4581,7 @@ BufferIsPermanent(Buffer buffer)
 	 * not random garbage.
 	 */
 	bufHdr = GetBufferDescriptor(buffer - 1);
-	return (pg_atomic_read_u32(&bufHdr->state) & BM_PERMANENT) != 0;
+	return (pg_atomic_read_u64(&bufHdr->state) & BM_PERMANENT) != 0;
 }
 
 /*
@@ -5044,11 +5044,11 @@ FlushRelationBuffers(Relation rel)
 	{
 		for (i = 0; i < NLocBuffer; i++)
 		{
-			uint32		buf_state;
+			uint64		buf_state;
 
 			bufHdr = GetLocalBufferDescriptor(i);
 			if (BufTagMatchesRelFileLocator(&bufHdr->tag, &rel->rd_locator) &&
-				((buf_state = pg_atomic_read_u32(&bufHdr->state)) &
+				((buf_state = pg_atomic_read_u64(&bufHdr->state)) &
 				 (BM_VALID | BM_DIRTY)) == (BM_VALID | BM_DIRTY))
 			{
 				ErrorContextCallback errcallback;
@@ -5084,7 +5084,7 @@ FlushRelationBuffers(Relation rel)
 
 	for (i = 0; i < NBuffers; i++)
 	{
-		uint32		buf_state;
+		uint64		buf_state;
 
 		bufHdr = GetBufferDescriptor(i);
 
@@ -5156,7 +5156,7 @@ FlushRelationsAllBuffers(SMgrRelation *smgrs, int nrels)
 	{
 		SMgrSortArray *srelent = NULL;
 		BufferDesc *bufHdr = GetBufferDescriptor(i);
-		uint32		buf_state;
+		uint64		buf_state;
 
 		/*
 		 * As in DropRelationBuffers, an unlocked precheck should be safe and
@@ -5405,7 +5405,7 @@ FlushDatabaseBuffers(Oid dbid)
 
 	for (i = 0; i < NBuffers; i++)
 	{
-		uint32		buf_state;
+		uint64		buf_state;
 
 		bufHdr = GetBufferDescriptor(i);
 
@@ -5553,13 +5553,13 @@ MarkBufferDirtyHint(Buffer buffer, bool buffer_std)
 	 * is only intended to be used in cases where failing to write out the
 	 * data would be harmless anyway, it doesn't really matter.
 	 */
-	if ((pg_atomic_read_u32(&bufHdr->state) & (BM_DIRTY | BM_JUST_DIRTIED)) !=
+	if ((pg_atomic_read_u64(&bufHdr->state) & (BM_DIRTY | BM_JUST_DIRTIED)) !=
 		(BM_DIRTY | BM_JUST_DIRTIED))
 	{
 		XLogRecPtr	lsn = InvalidXLogRecPtr;
 		bool		dirtied = false;
 		bool		delayChkptFlags = false;
-		uint32		buf_state;
+		uint64		buf_state;
 
 		/*
 		 * If we need to protect hint bit updates from torn writes, WAL-log a
@@ -5571,7 +5571,7 @@ MarkBufferDirtyHint(Buffer buffer, bool buffer_std)
 		 * when we call XLogInsert() since the value changes dynamically.
 		 */
 		if (XLogHintBitIsNeeded() &&
-			(pg_atomic_read_u32(&bufHdr->state) & BM_PERMANENT))
+			(pg_atomic_read_u64(&bufHdr->state) & BM_PERMANENT))
 		{
 			/*
 			 * If we must not write WAL, due to a relfilelocator-specific
@@ -5671,8 +5671,8 @@ UnlockBuffers(void)
 
 	if (buf)
 	{
-		uint32		buf_state;
-		uint32		unset_bits = 0;
+		uint64		buf_state;
+		uint64		unset_bits = 0;
 
 		buf_state = LockBufHdr(buf);
 
@@ -5803,8 +5803,8 @@ LockBufferForCleanup(Buffer buffer)
 
 	for (;;)
 	{
-		uint32		buf_state;
-		uint32		unset_bits = 0;
+		uint64		buf_state;
+		uint64		unset_bits = 0;
 
 		/* Try to acquire lock */
 		LockBuffer(buffer, BUFFER_LOCK_EXCLUSIVE);
@@ -5952,7 +5952,7 @@ bool
 ConditionalLockBufferForCleanup(Buffer buffer)
 {
 	BufferDesc *bufHdr;
-	uint32		buf_state,
+	uint64		buf_state,
 				refcount;
 
 	Assert(BufferIsValid(buffer));
@@ -6010,7 +6010,7 @@ bool
 IsBufferCleanupOK(Buffer buffer)
 {
 	BufferDesc *bufHdr;
-	uint32		buf_state;
+	uint64		buf_state;
 
 	Assert(BufferIsValid(buffer));
 
@@ -6066,7 +6066,7 @@ WaitIO(BufferDesc *buf)
 	ConditionVariablePrepareToSleep(cv);
 	for (;;)
 	{
-		uint32		buf_state;
+		uint64		buf_state;
 		PgAioWaitRef iow;
 
 		/*
@@ -6140,7 +6140,7 @@ WaitIO(BufferDesc *buf)
 bool
 StartBufferIO(BufferDesc *buf, bool forInput, bool nowait)
 {
-	uint32		buf_state;
+	uint64		buf_state;
 
 	ResourceOwnerEnlarge(CurrentResourceOwner);
 
@@ -6196,11 +6196,11 @@ StartBufferIO(BufferDesc *buf, bool forInput, bool nowait)
  * is being released)
  */
 void
-TerminateBufferIO(BufferDesc *buf, bool clear_dirty, uint32 set_flag_bits,
+TerminateBufferIO(BufferDesc *buf, bool clear_dirty, uint64 set_flag_bits,
 				  bool forget_owner, bool release_aio)
 {
-	uint32		buf_state;
-	uint32		unset_flag_bits = 0;
+	uint64		buf_state;
+	uint64		unset_flag_bits = 0;
 	int			refcount_change = 0;
 
 	buf_state = LockBufHdr(buf);
@@ -6261,7 +6261,7 @@ static void
 AbortBufferIO(Buffer buffer)
 {
 	BufferDesc *buf_hdr = GetBufferDescriptor(buffer - 1);
-	uint32		buf_state;
+	uint64		buf_state;
 
 	buf_state = LockBufHdr(buf_hdr);
 	Assert(buf_state & (BM_IO_IN_PROGRESS | BM_TAG_VALID));
@@ -6355,10 +6355,10 @@ rlocator_comparator(const void *p1, const void *p2)
 /*
  * Lock buffer header - set BM_LOCKED in buffer state.
  */
-uint32
+uint64
 LockBufHdr(BufferDesc *desc)
 {
-	uint32		old_buf_state;
+	uint64		old_buf_state;
 
 	Assert(!BufferIsLocal(BufferDescriptorGetBuffer(desc)));
 
@@ -6369,7 +6369,7 @@ LockBufHdr(BufferDesc *desc)
 		 * the spin-delay infrastructure. The work necessary for that shows up
 		 * in profiles and is rarely necessary.
 		 */
-		old_buf_state = pg_atomic_fetch_or_u32(&desc->state, BM_LOCKED);
+		old_buf_state = pg_atomic_fetch_or_u64(&desc->state, BM_LOCKED);
 		if (likely(!(old_buf_state & BM_LOCKED)))
 			break;				/* got lock */
 
@@ -6382,7 +6382,7 @@ LockBufHdr(BufferDesc *desc)
 			while (old_buf_state & BM_LOCKED)
 			{
 				perform_spin_delay(&delayStatus);
-				old_buf_state = pg_atomic_read_u32(&desc->state);
+				old_buf_state = pg_atomic_read_u64(&desc->state);
 			}
 			finish_spin_delay(&delayStatus);
 		}
@@ -6403,20 +6403,20 @@ LockBufHdr(BufferDesc *desc)
  * Obviously the buffer could be locked by the time the value is returned, so
  * this is primarily useful in CAS style loops.
  */
-pg_noinline uint32
+pg_noinline uint64
 WaitBufHdrUnlocked(BufferDesc *buf)
 {
 	SpinDelayStatus delayStatus;
-	uint32		buf_state;
+	uint64		buf_state;
 
 	init_local_spin_delay(&delayStatus);
 
-	buf_state = pg_atomic_read_u32(&buf->state);
+	buf_state = pg_atomic_read_u64(&buf->state);
 
 	while (buf_state & BM_LOCKED)
 	{
 		perform_spin_delay(&delayStatus);
-		buf_state = pg_atomic_read_u32(&buf->state);
+		buf_state = pg_atomic_read_u64(&buf->state);
 	}
 
 	finish_spin_delay(&delayStatus);
@@ -6704,12 +6704,12 @@ ResOwnerPrintBufferPin(Datum res)
 static bool
 EvictUnpinnedBufferInternal(BufferDesc *desc, bool *buffer_flushed)
 {
-	uint32		buf_state;
+	uint64		buf_state;
 	bool		result;
 
 	*buffer_flushed = false;
 
-	buf_state = pg_atomic_read_u32(&(desc->state));
+	buf_state = pg_atomic_read_u64(&(desc->state));
 	Assert(buf_state & BM_LOCKED);
 
 	if ((buf_state & BM_VALID) == 0)
@@ -6803,12 +6803,12 @@ EvictAllUnpinnedBuffers(int32 *buffers_evicted, int32 *buffers_flushed,
 	for (int buf = 1; buf <= NBuffers; buf++)
 	{
 		BufferDesc *desc = GetBufferDescriptor(buf - 1);
-		uint32		buf_state;
+		uint64		buf_state;
 		bool		buffer_flushed;
 
 		CHECK_FOR_INTERRUPTS();
 
-		buf_state = pg_atomic_read_u32(&desc->state);
+		buf_state = pg_atomic_read_u64(&desc->state);
 		if (!(buf_state & BM_VALID))
 			continue;
 
@@ -6855,7 +6855,7 @@ EvictRelUnpinnedBuffers(Relation rel, int32 *buffers_evicted,
 	for (int buf = 1; buf <= NBuffers; buf++)
 	{
 		BufferDesc *desc = GetBufferDescriptor(buf - 1);
-		uint32		buf_state = pg_atomic_read_u32(&(desc->state));
+		uint64		buf_state = pg_atomic_read_u64(&(desc->state));
 		bool		buffer_flushed;
 
 		CHECK_FOR_INTERRUPTS();
@@ -6897,12 +6897,12 @@ static bool
 MarkDirtyUnpinnedBufferInternal(Buffer buf, BufferDesc *desc,
 								bool *buffer_already_dirty)
 {
-	uint32		buf_state;
+	uint64		buf_state;
 	bool		result = false;
 
 	*buffer_already_dirty = false;
 
-	buf_state = pg_atomic_read_u32(&(desc->state));
+	buf_state = pg_atomic_read_u64(&(desc->state));
 	Assert(buf_state & BM_LOCKED);
 
 	if ((buf_state & BM_VALID) == 0)
@@ -7000,7 +7000,7 @@ MarkDirtyRelUnpinnedBuffers(Relation rel,
 	for (int buf = 1; buf <= NBuffers; buf++)
 	{
 		BufferDesc *desc = GetBufferDescriptor(buf - 1);
-		uint32		buf_state = pg_atomic_read_u32(&(desc->state));
+		uint64		buf_state = pg_atomic_read_u64(&(desc->state));
 		bool		buffer_already_dirty;
 
 		CHECK_FOR_INTERRUPTS();
@@ -7054,12 +7054,12 @@ MarkDirtyAllUnpinnedBuffers(int32 *buffers_dirtied,
 	for (int buf = 1; buf <= NBuffers; buf++)
 	{
 		BufferDesc *desc = GetBufferDescriptor(buf - 1);
-		uint32		buf_state;
+		uint64		buf_state;
 		bool		buffer_already_dirty;
 
 		CHECK_FOR_INTERRUPTS();
 
-		buf_state = pg_atomic_read_u32(&desc->state);
+		buf_state = pg_atomic_read_u64(&desc->state);
 		if (!(buf_state & BM_VALID))
 			continue;
 
@@ -7110,7 +7110,7 @@ buffer_stage_common(PgAioHandle *ioh, bool is_write, bool is_temp)
 		BufferDesc *buf_hdr = is_temp ?
 			GetLocalBufferDescriptor(-buffer - 1)
 			: GetBufferDescriptor(buffer - 1);
-		uint32		buf_state;
+		uint64		buf_state;
 
 		/*
 		 * Check that all the buffers are actually ones that could conceivably
@@ -7128,7 +7128,7 @@ buffer_stage_common(PgAioHandle *ioh, bool is_write, bool is_temp)
 		}
 
 		if (is_temp)
-			buf_state = pg_atomic_read_u32(&buf_hdr->state);
+			buf_state = pg_atomic_read_u64(&buf_hdr->state);
 		else
 			buf_state = LockBufHdr(buf_hdr);
 
@@ -7166,7 +7166,7 @@ buffer_stage_common(PgAioHandle *ioh, bool is_write, bool is_temp)
 		if (is_temp)
 		{
 			buf_state += BUF_REFCOUNT_ONE;
-			pg_atomic_unlocked_write_u32(&buf_hdr->state, buf_state);
+			pg_atomic_unlocked_write_u64(&buf_hdr->state, buf_state);
 		}
 		else
 			UnlockBufHdrExt(buf_hdr, buf_state, 0, 0, 1);
@@ -7352,13 +7352,13 @@ buffer_readv_complete_one(PgAioTargetData *td, uint8 buf_off, Buffer buffer,
 		: GetBufferDescriptor(buffer - 1);
 	BufferTag	tag = buf_hdr->tag;
 	char	   *bufdata = BufferGetBlock(buffer);
-	uint32		set_flag_bits;
+	uint64		set_flag_bits;
 	int			piv_flags;
 
 	/* check that the buffer is in the expected state for a read */
 #ifdef USE_ASSERT_CHECKING
 	{
-		uint32		buf_state = pg_atomic_read_u32(&buf_hdr->state);
+		uint64		buf_state = pg_atomic_read_u64(&buf_hdr->state);
 
 		Assert(buf_state & BM_TAG_VALID);
 		Assert(!(buf_state & BM_VALID));
diff --git a/src/backend/storage/buffer/freelist.c b/src/backend/storage/buffer/freelist.c
index 28d952b3534..1d4f19a9afd 100644
--- a/src/backend/storage/buffer/freelist.c
+++ b/src/backend/storage/buffer/freelist.c
@@ -86,7 +86,7 @@ typedef struct BufferAccessStrategyData
 
 /* Prototypes for internal functions */
 static BufferDesc *GetBufferFromRing(BufferAccessStrategy strategy,
-									 uint32 *buf_state);
+									 uint64 *buf_state);
 static void AddBufferToRing(BufferAccessStrategy strategy,
 							BufferDesc *buf);
 
@@ -171,7 +171,7 @@ ClockSweepTick(void)
  *	before returning.
  */
 BufferDesc *
-StrategyGetBuffer(BufferAccessStrategy strategy, uint32 *buf_state, bool *from_ring)
+StrategyGetBuffer(BufferAccessStrategy strategy, uint64 *buf_state, bool *from_ring)
 {
 	BufferDesc *buf;
 	int			bgwprocno;
@@ -230,8 +230,8 @@ StrategyGetBuffer(BufferAccessStrategy strategy, uint32 *buf_state, bool *from_r
 	trycounter = NBuffers;
 	for (;;)
 	{
-		uint32		old_buf_state;
-		uint32		local_buf_state;
+		uint64		old_buf_state;
+		uint64		local_buf_state;
 
 		buf = GetBufferDescriptor(ClockSweepTick());
 
@@ -239,7 +239,7 @@ StrategyGetBuffer(BufferAccessStrategy strategy, uint32 *buf_state, bool *from_r
 		 * Check whether the buffer can be used and pin it if so. Do this
 		 * using a CAS loop, to avoid having to lock the buffer header.
 		 */
-		old_buf_state = pg_atomic_read_u32(&buf->state);
+		old_buf_state = pg_atomic_read_u64(&buf->state);
 		for (;;)
 		{
 			local_buf_state = old_buf_state;
@@ -277,7 +277,7 @@ StrategyGetBuffer(BufferAccessStrategy strategy, uint32 *buf_state, bool *from_r
 			{
 				local_buf_state -= BUF_USAGECOUNT_ONE;
 
-				if (pg_atomic_compare_exchange_u32(&buf->state, &old_buf_state,
+				if (pg_atomic_compare_exchange_u64(&buf->state, &old_buf_state,
 												   local_buf_state))
 				{
 					trycounter = NBuffers;
@@ -289,7 +289,7 @@ StrategyGetBuffer(BufferAccessStrategy strategy, uint32 *buf_state, bool *from_r
 				/* pin the buffer if the CAS succeeds */
 				local_buf_state += BUF_REFCOUNT_ONE;
 
-				if (pg_atomic_compare_exchange_u32(&buf->state, &old_buf_state,
+				if (pg_atomic_compare_exchange_u64(&buf->state, &old_buf_state,
 												   local_buf_state))
 				{
 					/* Found a usable buffer */
@@ -655,12 +655,12 @@ FreeAccessStrategy(BufferAccessStrategy strategy)
  * returning.
  */
 static BufferDesc *
-GetBufferFromRing(BufferAccessStrategy strategy, uint32 *buf_state)
+GetBufferFromRing(BufferAccessStrategy strategy, uint64 *buf_state)
 {
 	BufferDesc *buf;
 	Buffer		bufnum;
-	uint32		old_buf_state;
-	uint32		local_buf_state;	/* to avoid repeated (de-)referencing */
+	uint64		old_buf_state;
+	uint64		local_buf_state;	/* to avoid repeated (de-)referencing */
 
 
 	/* Advance to next ring slot */
@@ -682,7 +682,7 @@ GetBufferFromRing(BufferAccessStrategy strategy, uint32 *buf_state)
 	 * Check whether the buffer can be used and pin it if so. Do this using a
 	 * CAS loop, to avoid having to lock the buffer header.
 	 */
-	old_buf_state = pg_atomic_read_u32(&buf->state);
+	old_buf_state = pg_atomic_read_u64(&buf->state);
 	for (;;)
 	{
 		local_buf_state = old_buf_state;
@@ -710,7 +710,7 @@ GetBufferFromRing(BufferAccessStrategy strategy, uint32 *buf_state)
 		/* pin the buffer if the CAS succeeds */
 		local_buf_state += BUF_REFCOUNT_ONE;
 
-		if (pg_atomic_compare_exchange_u32(&buf->state, &old_buf_state,
+		if (pg_atomic_compare_exchange_u64(&buf->state, &old_buf_state,
 										   local_buf_state))
 		{
 			*buf_state = local_buf_state;
diff --git a/src/backend/storage/buffer/localbuf.c b/src/backend/storage/buffer/localbuf.c
index 15aac7d1c9f..a41a5facd3a 100644
--- a/src/backend/storage/buffer/localbuf.c
+++ b/src/backend/storage/buffer/localbuf.c
@@ -148,7 +148,7 @@ LocalBufferAlloc(SMgrRelation smgr, ForkNumber forkNum, BlockNumber blockNum,
 	}
 	else
 	{
-		uint32		buf_state;
+		uint64		buf_state;
 
 		victim_buffer = GetLocalVictimBuffer();
 		bufid = -victim_buffer - 1;
@@ -165,10 +165,10 @@ LocalBufferAlloc(SMgrRelation smgr, ForkNumber forkNum, BlockNumber blockNum,
 		 */
 		bufHdr->tag = newTag;
 
-		buf_state = pg_atomic_read_u32(&bufHdr->state);
+		buf_state = pg_atomic_read_u64(&bufHdr->state);
 		buf_state &= ~(BUF_FLAG_MASK | BUF_USAGECOUNT_MASK);
 		buf_state |= BM_TAG_VALID | BUF_USAGECOUNT_ONE;
-		pg_atomic_unlocked_write_u32(&bufHdr->state, buf_state);
+		pg_atomic_unlocked_write_u64(&bufHdr->state, buf_state);
 
 		*foundPtr = false;
 	}
@@ -245,12 +245,12 @@ GetLocalVictimBuffer(void)
 
 		if (LocalRefCount[victim_bufid] == 0)
 		{
-			uint32		buf_state = pg_atomic_read_u32(&bufHdr->state);
+			uint64		buf_state = pg_atomic_read_u64(&bufHdr->state);
 
 			if (BUF_STATE_GET_USAGECOUNT(buf_state) > 0)
 			{
 				buf_state -= BUF_USAGECOUNT_ONE;
-				pg_atomic_unlocked_write_u32(&bufHdr->state, buf_state);
+				pg_atomic_unlocked_write_u64(&bufHdr->state, buf_state);
 				trycounter = NLocBuffer;
 			}
 			else if (BUF_STATE_GET_REFCOUNT(buf_state) > 0)
@@ -286,13 +286,13 @@ GetLocalVictimBuffer(void)
 	 * this buffer is not referenced but it might still be dirty. if that's
 	 * the case, write it out before reusing it!
 	 */
-	if (pg_atomic_read_u32(&bufHdr->state) & BM_DIRTY)
+	if (pg_atomic_read_u64(&bufHdr->state) & BM_DIRTY)
 		FlushLocalBuffer(bufHdr, NULL);
 
 	/*
 	 * Remove the victim buffer from the hashtable and mark as invalid.
 	 */
-	if (pg_atomic_read_u32(&bufHdr->state) & BM_TAG_VALID)
+	if (pg_atomic_read_u64(&bufHdr->state) & BM_TAG_VALID)
 	{
 		InvalidateLocalBuffer(bufHdr, false);
 
@@ -417,7 +417,7 @@ ExtendBufferedRelLocal(BufferManagerRelation bmr,
 		if (found)
 		{
 			BufferDesc *existing_hdr;
-			uint32		buf_state;
+			uint64		buf_state;
 
 			UnpinLocalBuffer(BufferDescriptorGetBuffer(victim_buf_hdr));
 
@@ -428,18 +428,18 @@ ExtendBufferedRelLocal(BufferManagerRelation bmr,
 			/*
 			 * Clear the BM_VALID bit, do StartLocalBufferIO() and proceed.
 			 */
-			buf_state = pg_atomic_read_u32(&existing_hdr->state);
+			buf_state = pg_atomic_read_u64(&existing_hdr->state);
 			Assert(buf_state & BM_TAG_VALID);
 			Assert(!(buf_state & BM_DIRTY));
 			buf_state &= ~BM_VALID;
-			pg_atomic_unlocked_write_u32(&existing_hdr->state, buf_state);
+			pg_atomic_unlocked_write_u64(&existing_hdr->state, buf_state);
 
 			/* no need to loop for local buffers */
 			StartLocalBufferIO(existing_hdr, true, false);
 		}
 		else
 		{
-			uint32		buf_state = pg_atomic_read_u32(&victim_buf_hdr->state);
+			uint64		buf_state = pg_atomic_read_u64(&victim_buf_hdr->state);
 
 			Assert(!(buf_state & (BM_VALID | BM_TAG_VALID | BM_DIRTY | BM_JUST_DIRTIED)));
 
@@ -447,7 +447,7 @@ ExtendBufferedRelLocal(BufferManagerRelation bmr,
 
 			buf_state |= BM_TAG_VALID | BUF_USAGECOUNT_ONE;
 
-			pg_atomic_unlocked_write_u32(&victim_buf_hdr->state, buf_state);
+			pg_atomic_unlocked_write_u64(&victim_buf_hdr->state, buf_state);
 
 			hresult->id = victim_buf_id;
 
@@ -467,13 +467,13 @@ ExtendBufferedRelLocal(BufferManagerRelation bmr,
 	{
 		Buffer		buf = buffers[i];
 		BufferDesc *buf_hdr;
-		uint32		buf_state;
+		uint64		buf_state;
 
 		buf_hdr = GetLocalBufferDescriptor(-buf - 1);
 
-		buf_state = pg_atomic_read_u32(&buf_hdr->state);
+		buf_state = pg_atomic_read_u64(&buf_hdr->state);
 		buf_state |= BM_VALID;
-		pg_atomic_unlocked_write_u32(&buf_hdr->state, buf_state);
+		pg_atomic_unlocked_write_u64(&buf_hdr->state, buf_state);
 	}
 
 	*extended_by = extend_by;
@@ -492,7 +492,7 @@ MarkLocalBufferDirty(Buffer buffer)
 {
 	int			bufid;
 	BufferDesc *bufHdr;
-	uint32		buf_state;
+	uint64		buf_state;
 
 	Assert(BufferIsLocal(buffer));
 
@@ -506,14 +506,14 @@ MarkLocalBufferDirty(Buffer buffer)
 
 	bufHdr = GetLocalBufferDescriptor(bufid);
 
-	buf_state = pg_atomic_read_u32(&bufHdr->state);
+	buf_state = pg_atomic_read_u64(&bufHdr->state);
 
 	if (!(buf_state & BM_DIRTY))
 		pgBufferUsage.local_blks_dirtied++;
 
 	buf_state |= BM_DIRTY;
 
-	pg_atomic_unlocked_write_u32(&bufHdr->state, buf_state);
+	pg_atomic_unlocked_write_u64(&bufHdr->state, buf_state);
 }
 
 /*
@@ -522,7 +522,7 @@ MarkLocalBufferDirty(Buffer buffer)
 bool
 StartLocalBufferIO(BufferDesc *bufHdr, bool forInput, bool nowait)
 {
-	uint32		buf_state;
+	uint64		buf_state;
 
 	/*
 	 * With AIO the buffer could have IO in progress, e.g. when there are two
@@ -542,7 +542,7 @@ StartLocalBufferIO(BufferDesc *bufHdr, bool forInput, bool nowait)
 	/* Once we get here, there is definitely no I/O active on this buffer */
 
 	/* Check if someone else already did the I/O */
-	buf_state = pg_atomic_read_u32(&bufHdr->state);
+	buf_state = pg_atomic_read_u64(&bufHdr->state);
 	if (forInput ? (buf_state & BM_VALID) : !(buf_state & BM_DIRTY))
 	{
 		return false;
@@ -559,11 +559,11 @@ StartLocalBufferIO(BufferDesc *bufHdr, bool forInput, bool nowait)
  * Like TerminateBufferIO, but for local buffers
  */
 void
-TerminateLocalBufferIO(BufferDesc *bufHdr, bool clear_dirty, uint32 set_flag_bits,
+TerminateLocalBufferIO(BufferDesc *bufHdr, bool clear_dirty, uint64 set_flag_bits,
 					   bool release_aio)
 {
 	/* Only need to adjust flags */
-	uint32		buf_state = pg_atomic_read_u32(&bufHdr->state);
+	uint64		buf_state = pg_atomic_read_u64(&bufHdr->state);
 
 	/* BM_IO_IN_PROGRESS isn't currently used for local buffers */
 
@@ -582,7 +582,7 @@ TerminateLocalBufferIO(BufferDesc *bufHdr, bool clear_dirty, uint32 set_flag_bit
 	}
 
 	buf_state |= set_flag_bits;
-	pg_atomic_unlocked_write_u32(&bufHdr->state, buf_state);
+	pg_atomic_unlocked_write_u64(&bufHdr->state, buf_state);
 
 	/* local buffers don't track IO using resowners */
 
@@ -606,7 +606,7 @@ InvalidateLocalBuffer(BufferDesc *bufHdr, bool check_unreferenced)
 {
 	Buffer		buffer = BufferDescriptorGetBuffer(bufHdr);
 	int			bufid = -buffer - 1;
-	uint32		buf_state;
+	uint64		buf_state;
 	LocalBufferLookupEnt *hresult;
 
 	/*
@@ -622,7 +622,7 @@ InvalidateLocalBuffer(BufferDesc *bufHdr, bool check_unreferenced)
 		Assert(!pgaio_wref_valid(&bufHdr->io_wref));
 	}
 
-	buf_state = pg_atomic_read_u32(&bufHdr->state);
+	buf_state = pg_atomic_read_u64(&bufHdr->state);
 
 	/*
 	 * We need to test not just LocalRefCount[bufid] but also the BufferDesc
@@ -647,7 +647,7 @@ InvalidateLocalBuffer(BufferDesc *bufHdr, bool check_unreferenced)
 	ClearBufferTag(&bufHdr->tag);
 	buf_state &= ~BUF_FLAG_MASK;
 	buf_state &= ~BUF_USAGECOUNT_MASK;
-	pg_atomic_unlocked_write_u32(&bufHdr->state, buf_state);
+	pg_atomic_unlocked_write_u64(&bufHdr->state, buf_state);
 }
 
 /*
@@ -671,9 +671,9 @@ DropRelationLocalBuffers(RelFileLocator rlocator, ForkNumber *forkNum,
 	for (i = 0; i < NLocBuffer; i++)
 	{
 		BufferDesc *bufHdr = GetLocalBufferDescriptor(i);
-		uint32		buf_state;
+		uint64		buf_state;
 
-		buf_state = pg_atomic_read_u32(&bufHdr->state);
+		buf_state = pg_atomic_read_u64(&bufHdr->state);
 
 		if (!(buf_state & BM_TAG_VALID) ||
 			!BufTagMatchesRelFileLocator(&bufHdr->tag, &rlocator))
@@ -706,9 +706,9 @@ DropRelationAllLocalBuffers(RelFileLocator rlocator)
 	for (i = 0; i < NLocBuffer; i++)
 	{
 		BufferDesc *bufHdr = GetLocalBufferDescriptor(i);
-		uint32		buf_state;
+		uint64		buf_state;
 
-		buf_state = pg_atomic_read_u32(&bufHdr->state);
+		buf_state = pg_atomic_read_u64(&bufHdr->state);
 
 		if ((buf_state & BM_TAG_VALID) &&
 			BufTagMatchesRelFileLocator(&bufHdr->tag, &rlocator))
@@ -804,11 +804,11 @@ InitLocalBuffers(void)
 bool
 PinLocalBuffer(BufferDesc *buf_hdr, bool adjust_usagecount)
 {
-	uint32		buf_state;
+	uint64		buf_state;
 	Buffer		buffer = BufferDescriptorGetBuffer(buf_hdr);
 	int			bufid = -buffer - 1;
 
-	buf_state = pg_atomic_read_u32(&buf_hdr->state);
+	buf_state = pg_atomic_read_u64(&buf_hdr->state);
 
 	if (LocalRefCount[bufid] == 0)
 	{
@@ -819,7 +819,7 @@ PinLocalBuffer(BufferDesc *buf_hdr, bool adjust_usagecount)
 		{
 			buf_state += BUF_USAGECOUNT_ONE;
 		}
-		pg_atomic_unlocked_write_u32(&buf_hdr->state, buf_state);
+		pg_atomic_unlocked_write_u64(&buf_hdr->state, buf_state);
 
 		/*
 		 * See comment in PinBuffer().
@@ -856,14 +856,14 @@ UnpinLocalBufferNoOwner(Buffer buffer)
 	if (--LocalRefCount[buffid] == 0)
 	{
 		BufferDesc *buf_hdr = GetLocalBufferDescriptor(buffid);
-		uint32		buf_state;
+		uint64		buf_state;
 
 		NLocalPinnedBuffers--;
 
-		buf_state = pg_atomic_read_u32(&buf_hdr->state);
+		buf_state = pg_atomic_read_u64(&buf_hdr->state);
 		Assert(BUF_STATE_GET_REFCOUNT(buf_state) > 0);
 		buf_state -= BUF_REFCOUNT_ONE;
-		pg_atomic_unlocked_write_u32(&buf_hdr->state, buf_state);
+		pg_atomic_unlocked_write_u64(&buf_hdr->state, buf_state);
 
 		/* see comment in UnpinBufferNoOwner */
 		VALGRIND_MAKE_MEM_NOACCESS(LocalBufHdrGetBlock(buf_hdr), BLCKSZ);
diff --git a/contrib/pg_buffercache/pg_buffercache_pages.c b/contrib/pg_buffercache/pg_buffercache_pages.c
index 0c58e4b265c..529803346ce 100644
--- a/contrib/pg_buffercache/pg_buffercache_pages.c
+++ b/contrib/pg_buffercache/pg_buffercache_pages.c
@@ -199,7 +199,7 @@ pg_buffercache_pages(PG_FUNCTION_ARGS)
 		for (i = 0; i < NBuffers; i++)
 		{
 			BufferDesc *bufHdr;
-			uint32		buf_state;
+			uint64		buf_state;
 
 			CHECK_FOR_INTERRUPTS();
 
@@ -615,7 +615,7 @@ pg_buffercache_summary(PG_FUNCTION_ARGS)
 	for (int i = 0; i < NBuffers; i++)
 	{
 		BufferDesc *bufHdr;
-		uint32		buf_state;
+		uint64		buf_state;
 
 		CHECK_FOR_INTERRUPTS();
 
@@ -626,7 +626,7 @@ pg_buffercache_summary(PG_FUNCTION_ARGS)
 		 * noticeably increase the cost of the function.
 		 */
 		bufHdr = GetBufferDescriptor(i);
-		buf_state = pg_atomic_read_u32(&bufHdr->state);
+		buf_state = pg_atomic_read_u64(&bufHdr->state);
 
 		if (buf_state & BM_VALID)
 		{
@@ -676,7 +676,7 @@ pg_buffercache_usage_counts(PG_FUNCTION_ARGS)
 	for (int i = 0; i < NBuffers; i++)
 	{
 		BufferDesc *bufHdr = GetBufferDescriptor(i);
-		uint32		buf_state = pg_atomic_read_u32(&bufHdr->state);
+		uint64		buf_state = pg_atomic_read_u64(&bufHdr->state);
 		int			usage_count;
 
 		CHECK_FOR_INTERRUPTS();
diff --git a/src/test/modules/test_aio/test_aio.c b/src/test/modules/test_aio/test_aio.c
index d7eadeab256..488d98e7e66 100644
--- a/src/test/modules/test_aio/test_aio.c
+++ b/src/test/modules/test_aio/test_aio.c
@@ -308,9 +308,9 @@ create_toy_buffer(Relation rel, BlockNumber blkno)
 {
 	Buffer		buf;
 	BufferDesc *buf_hdr;
-	uint32		buf_state;
+	uint64		buf_state;
 	bool		was_pinned = false;
-	uint32		unset_bits = 0;
+	uint64		unset_bits = 0;
 
 	/* place buffer in shared buffers without erroring out */
 	buf = ReadBufferExtended(rel, MAIN_FORKNUM, blkno, RBM_ZERO_AND_LOCK, NULL);
@@ -319,7 +319,7 @@ create_toy_buffer(Relation rel, BlockNumber blkno)
 	if (RelationUsesLocalBuffers(rel))
 	{
 		buf_hdr = GetLocalBufferDescriptor(-buf - 1);
-		buf_state = pg_atomic_read_u32(&buf_hdr->state);
+		buf_state = pg_atomic_read_u64(&buf_hdr->state);
 	}
 	else
 	{
@@ -340,7 +340,7 @@ create_toy_buffer(Relation rel, BlockNumber blkno)
 	if (RelationUsesLocalBuffers(rel))
 	{
 		buf_state &= ~unset_bits;
-		pg_atomic_unlocked_write_u32(&buf_hdr->state, buf_state);
+		pg_atomic_unlocked_write_u64(&buf_hdr->state, buf_state);
 	}
 	else
 	{
@@ -489,7 +489,7 @@ invalidate_rel_block(PG_FUNCTION_ARGS)
 
 			LockBuffer(buf, BUFFER_LOCK_EXCLUSIVE);
 
-			if (pg_atomic_read_u32(&buf_hdr->state) & BM_DIRTY)
+			if (pg_atomic_read_u64(&buf_hdr->state) & BM_DIRTY)
 			{
 				if (BufferIsLocal(buf))
 					FlushLocalBuffer(buf_hdr, NULL);
@@ -572,7 +572,7 @@ buffer_call_terminate_io(PG_FUNCTION_ARGS)
 	bool		io_error = PG_GETARG_BOOL(3);
 	bool		release_aio = PG_GETARG_BOOL(4);
 	bool		clear_dirty = false;
-	uint32		set_flag_bits = 0;
+	uint64		set_flag_bits = 0;
 
 	if (io_error)
 		set_flag_bits |= BM_IO_ERROR;
-- 
2.48.1.76.g4e746b1a31.dirty


--lbbj3oq7cjvyhmbk
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
	filename="v8-0007-bufmgr-Implement-buffer-content-locks-independent.patch"



^ permalink  raw  reply  [nested|flat] 129+ messages in thread

* [PATCH v11 1/7] bufmgr: Change BufferDesc.state to be a 64-bit atomic
@ 2026-01-14 01:10  Andres Freund <andres@anarazel.de>
  0 siblings, 0 replies; 129+ messages in thread

From: Andres Freund @ 2026-01-14 01:10 UTC (permalink / raw)

This is motivated by wanting to merge buffer content locks into
BufferDesc.state in a future commit, rather than having a separate lwlock (see
commit c75ebc657ff for more details). As this change is rather mechanical, it
seems to make sense to split it out into a separate commit, for easier review.

Reviewed-by: Melanie Plageman <melanieplageman@gmail.com>
Discussion: https://postgr.es/m/fvfmkr5kk4nyex56ejgxj3uzi63isfxovp2biecb4bspbjrze7@az2pljabhnff
---
 src/include/storage/buf_internals.h           |  51 +++---
 src/include/storage/procnumber.h              |  14 +-
 src/backend/storage/buffer/buf_init.c         |   2 +-
 src/backend/storage/buffer/bufmgr.c           | 170 +++++++++---------
 src/backend/storage/buffer/freelist.c         |  24 +--
 src/backend/storage/buffer/localbuf.c         |  72 ++++----
 contrib/pg_buffercache/pg_buffercache_pages.c |   8 +-
 contrib/pg_prewarm/autoprewarm.c              |   2 +-
 src/test/modules/test_aio/test_aio.c          |  12 +-
 9 files changed, 179 insertions(+), 176 deletions(-)

diff --git a/src/include/storage/buf_internals.h b/src/include/storage/buf_internals.h
index 2f607ea2ac5..e6e788224f5 100644
--- a/src/include/storage/buf_internals.h
+++ b/src/include/storage/buf_internals.h
@@ -30,7 +30,7 @@
 #include "utils/resowner.h"
 
 /*
- * Buffer state is a single 32-bit variable where following data is combined.
+ * Buffer state is a single 64-bit variable where following data is combined.
  *
  * State of the buffer itself (in order):
  * - 18 bits refcount
@@ -40,6 +40,9 @@
  * Combining these values allows to perform some operations without locking
  * the buffer header, by modifying them together with a CAS loop.
  *
+ * NB: A future commit will use a significant portion of the remaining bits to
+ * implement buffer locking as part of the state variable.
+ *
  * The definition of buffer state components is below.
  */
 #define BUF_REFCOUNT_BITS 18
@@ -52,27 +55,27 @@ StaticAssertDecl(BUF_REFCOUNT_BITS + BUF_USAGECOUNT_BITS + BUF_FLAG_BITS == 32,
 /* refcount related definitions */
 #define BUF_REFCOUNT_ONE 1
 #define BUF_REFCOUNT_MASK \
-	((1U << BUF_REFCOUNT_BITS) - 1)
+	((UINT64CONST(1) << BUF_REFCOUNT_BITS) - 1)
 
 /* usage count related definitions */
 #define BUF_USAGECOUNT_SHIFT \
 	BUF_REFCOUNT_BITS
 #define BUF_USAGECOUNT_MASK \
-	(((1U << BUF_USAGECOUNT_BITS) - 1) << (BUF_USAGECOUNT_SHIFT))
+	(((UINT64CONST(1) << BUF_USAGECOUNT_BITS) - 1) << (BUF_USAGECOUNT_SHIFT))
 #define BUF_USAGECOUNT_ONE \
-	(1U << BUF_REFCOUNT_BITS)
+	(UINT64CONST(1) << BUF_REFCOUNT_BITS)
 
 /* flags related definitions */
 #define BUF_FLAG_SHIFT \
 	(BUF_REFCOUNT_BITS + BUF_USAGECOUNT_BITS)
 #define BUF_FLAG_MASK \
-	(((1U << BUF_FLAG_BITS) - 1) << BUF_FLAG_SHIFT)
+	(((UINT64CONST(1) << BUF_FLAG_BITS) - 1) << BUF_FLAG_SHIFT)
 
 /* Get refcount and usagecount from buffer state */
 #define BUF_STATE_GET_REFCOUNT(state) \
-	((state) & BUF_REFCOUNT_MASK)
+	((uint32)((state) & BUF_REFCOUNT_MASK))
 #define BUF_STATE_GET_USAGECOUNT(state) \
-	(((state) & BUF_USAGECOUNT_MASK) >> BUF_USAGECOUNT_SHIFT)
+	((uint32)(((state) & BUF_USAGECOUNT_MASK) >> BUF_USAGECOUNT_SHIFT))
 
 /*
  * Flags for buffer descriptors
@@ -82,7 +85,7 @@ StaticAssertDecl(BUF_REFCOUNT_BITS + BUF_USAGECOUNT_BITS + BUF_FLAG_BITS == 32,
  */
 
 #define BUF_DEFINE_FLAG(flagno)	\
-	(1U << (BUF_REFCOUNT_BITS + BUF_USAGECOUNT_BITS + (flagno)))
+	(UINT64CONST(1) << (BUF_FLAG_SHIFT + (flagno)))
 
 /* buffer header is locked */
 #define BM_LOCKED					BUF_DEFINE_FLAG( 0)
@@ -115,7 +118,7 @@ StaticAssertDecl(BUF_REFCOUNT_BITS + BUF_USAGECOUNT_BITS + BUF_FLAG_BITS == 32,
  */
 #define BM_MAX_USAGE_COUNT	5
 
-StaticAssertDecl(BM_MAX_USAGE_COUNT < (1 << BUF_USAGECOUNT_BITS),
+StaticAssertDecl(BM_MAX_USAGE_COUNT < (UINT64CONST(1) << BUF_USAGECOUNT_BITS),
 				 "BM_MAX_USAGE_COUNT doesn't fit in BUF_USAGECOUNT_BITS bits");
 StaticAssertDecl(MAX_BACKENDS_BITS <= BUF_REFCOUNT_BITS,
 				 "MAX_BACKENDS_BITS needs to be <= BUF_REFCOUNT_BITS");
@@ -280,8 +283,8 @@ BufMappingPartitionLockByIndex(uint32 index)
  * We use this same struct for local buffer headers, but the locks are not
  * used and not all of the flag bits are useful either. To avoid unnecessary
  * overhead, manipulations of the state field should be done without actual
- * atomic operations (i.e. only pg_atomic_read_u32() and
- * pg_atomic_unlocked_write_u32()).
+ * atomic operations (i.e. only pg_atomic_read_u64() and
+ * pg_atomic_unlocked_write_u64()).
  *
  * Be careful to avoid increasing the size of the struct when adding or
  * reordering members.  Keeping it below 64 bytes (the most common CPU
@@ -309,7 +312,7 @@ typedef struct BufferDesc
 	 * State of the buffer, containing flags, refcount and usagecount. See
 	 * BUF_* and BM_* defines at the top of this file.
 	 */
-	pg_atomic_uint32 state;
+	pg_atomic_uint64 state;
 
 	/*
 	 * Backend of pin-count waiter. The buffer header spinlock needs to be
@@ -415,7 +418,7 @@ BufferDescriptorGetContentLock(const BufferDesc *bdesc)
  * Functions for acquiring/releasing a shared buffer header's spinlock.  Do
  * not apply these to local buffers!
  */
-extern uint32 LockBufHdr(BufferDesc *desc);
+extern uint64 LockBufHdr(BufferDesc *desc);
 
 /*
  * Unlock the buffer header.
@@ -426,9 +429,9 @@ extern uint32 LockBufHdr(BufferDesc *desc);
 static inline void
 UnlockBufHdr(BufferDesc *desc)
 {
-	Assert(pg_atomic_read_u32(&desc->state) & BM_LOCKED);
+	Assert(pg_atomic_read_u64(&desc->state) & BM_LOCKED);
 
-	pg_atomic_fetch_sub_u32(&desc->state, BM_LOCKED);
+	pg_atomic_fetch_sub_u64(&desc->state, BM_LOCKED);
 }
 
 /*
@@ -439,14 +442,14 @@ UnlockBufHdr(BufferDesc *desc)
  * Note that this approach would not work for usagecount, since we need to cap
  * the usagecount at BM_MAX_USAGE_COUNT.
  */
-static inline uint32
-UnlockBufHdrExt(BufferDesc *desc, uint32 old_buf_state,
-				uint32 set_bits, uint32 unset_bits,
+static inline uint64
+UnlockBufHdrExt(BufferDesc *desc, uint64 old_buf_state,
+				uint64 set_bits, uint64 unset_bits,
 				int refcount_change)
 {
 	for (;;)
 	{
-		uint32		buf_state = old_buf_state;
+		uint64		buf_state = old_buf_state;
 
 		Assert(buf_state & BM_LOCKED);
 
@@ -457,7 +460,7 @@ UnlockBufHdrExt(BufferDesc *desc, uint32 old_buf_state,
 		if (refcount_change != 0)
 			buf_state += BUF_REFCOUNT_ONE * refcount_change;
 
-		if (pg_atomic_compare_exchange_u32(&desc->state, &old_buf_state,
+		if (pg_atomic_compare_exchange_u64(&desc->state, &old_buf_state,
 										   buf_state))
 		{
 			return old_buf_state;
@@ -465,7 +468,7 @@ UnlockBufHdrExt(BufferDesc *desc, uint32 old_buf_state,
 	}
 }
 
-extern uint32 WaitBufHdrUnlocked(BufferDesc *buf);
+extern uint64 WaitBufHdrUnlocked(BufferDesc *buf);
 
 /* in bufmgr.c */
 
@@ -525,14 +528,14 @@ extern void TrackNewBufferPin(Buffer buf);
 
 /* solely to make it easier to write tests */
 extern bool StartBufferIO(BufferDesc *buf, bool forInput, bool nowait);
-extern void TerminateBufferIO(BufferDesc *buf, bool clear_dirty, uint32 set_flag_bits,
+extern void TerminateBufferIO(BufferDesc *buf, bool clear_dirty, uint64 set_flag_bits,
 							  bool forget_owner, bool release_aio);
 
 
 /* freelist.c */
 extern IOContext IOContextForStrategy(BufferAccessStrategy strategy);
 extern BufferDesc *StrategyGetBuffer(BufferAccessStrategy strategy,
-									 uint32 *buf_state, bool *from_ring);
+									 uint64 *buf_state, bool *from_ring);
 extern bool StrategyRejectBuffer(BufferAccessStrategy strategy,
 								 BufferDesc *buf, bool from_ring);
 
@@ -568,7 +571,7 @@ extern BlockNumber ExtendBufferedRelLocal(BufferManagerRelation bmr,
 										  uint32 *extended_by);
 extern void MarkLocalBufferDirty(Buffer buffer);
 extern void TerminateLocalBufferIO(BufferDesc *bufHdr, bool clear_dirty,
-								   uint32 set_flag_bits, bool release_aio);
+								   uint64 set_flag_bits, bool release_aio);
 extern bool StartLocalBufferIO(BufferDesc *bufHdr, bool forInput, bool nowait);
 extern void FlushLocalBuffer(BufferDesc *bufHdr, SMgrRelation reln);
 extern void InvalidateLocalBuffer(BufferDesc *bufHdr, bool check_unreferenced);
diff --git a/src/include/storage/procnumber.h b/src/include/storage/procnumber.h
index 30c360ad350..bd9cb3891cc 100644
--- a/src/include/storage/procnumber.h
+++ b/src/include/storage/procnumber.h
@@ -27,13 +27,13 @@ typedef int ProcNumber;
 
 /*
  * Note: MAX_BACKENDS_BITS is 18 as that is the space available for buffer
- * refcounts in buf_internals.h.  This limitation could be lifted by using a
- * 64bit state; but it's unlikely to be worthwhile as 2^18-1 backends exceed
- * currently realistic configurations. Even if that limitation were removed,
- * we still could not a) exceed 2^23-1 because inval.c stores the ProcNumber
- * as a 3-byte signed integer, b) INT_MAX/4 because some places compute
- * 4*MaxBackends without any overflow check.  We check that the configured
- * number of backends does not exceed MAX_BACKENDS in InitializeMaxBackends().
+ * refcounts in buf_internals.h.  This limitation could be lifted, but it's
+ * unlikely to be worthwhile as 2^18-1 backends exceed currently realistic
+ * configurations. Even if that limitation were removed, we still could not a)
+ * exceed 2^23-1 because inval.c stores the ProcNumber as a 3-byte signed
+ * integer, b) INT_MAX/4 because some places compute 4*MaxBackends without any
+ * overflow check.  We check that the configured number of backends does not
+ * exceed MAX_BACKENDS in InitializeMaxBackends().
  */
 #define MAX_BACKENDS_BITS		18
 #define MAX_BACKENDS			((1U << MAX_BACKENDS_BITS)-1)
diff --git a/src/backend/storage/buffer/buf_init.c b/src/backend/storage/buffer/buf_init.c
index 9a312bcc7b3..7d894522526 100644
--- a/src/backend/storage/buffer/buf_init.c
+++ b/src/backend/storage/buffer/buf_init.c
@@ -121,7 +121,7 @@ BufferManagerShmemInit(void)
 
 			ClearBufferTag(&buf->tag);
 
-			pg_atomic_init_u32(&buf->state, 0);
+			pg_atomic_init_u64(&buf->state, 0);
 			buf->wait_backend_pgprocno = INVALID_PROC_NUMBER;
 
 			buf->buf_id = i;
diff --git a/src/backend/storage/buffer/bufmgr.c b/src/backend/storage/buffer/bufmgr.c
index a036c2aa275..b0de8e45d4d 100644
--- a/src/backend/storage/buffer/bufmgr.c
+++ b/src/backend/storage/buffer/bufmgr.c
@@ -780,7 +780,7 @@ ReadRecentBuffer(RelFileLocator rlocator, ForkNumber forkNum, BlockNumber blockN
 {
 	BufferDesc *bufHdr;
 	BufferTag	tag;
-	uint32		buf_state;
+	uint64		buf_state;
 
 	Assert(BufferIsValid(recent_buffer));
 
@@ -793,7 +793,7 @@ ReadRecentBuffer(RelFileLocator rlocator, ForkNumber forkNum, BlockNumber blockN
 		int			b = -recent_buffer - 1;
 
 		bufHdr = GetLocalBufferDescriptor(b);
-		buf_state = pg_atomic_read_u32(&bufHdr->state);
+		buf_state = pg_atomic_read_u64(&bufHdr->state);
 
 		/* Is it still valid and holding the right tag? */
 		if ((buf_state & BM_VALID) && BufferTagsEqual(&tag, &bufHdr->tag))
@@ -1386,8 +1386,8 @@ StartReadBuffersImpl(ReadBuffersOperation *operation,
 				bufHdr = GetLocalBufferDescriptor(-buffers[i] - 1);
 			else
 				bufHdr = GetBufferDescriptor(buffers[i] - 1);
-			Assert(pg_atomic_read_u32(&bufHdr->state) & BM_TAG_VALID);
-			found = pg_atomic_read_u32(&bufHdr->state) & BM_VALID;
+			Assert(pg_atomic_read_u64(&bufHdr->state) & BM_TAG_VALID);
+			found = pg_atomic_read_u64(&bufHdr->state) & BM_VALID;
 		}
 		else
 		{
@@ -1613,10 +1613,10 @@ CheckReadBuffersOperation(ReadBuffersOperation *operation, bool is_complete)
 			GetBufferDescriptor(buffer - 1);
 
 		Assert(BufferGetBlockNumber(buffer) == operation->blocknum + i);
-		Assert(pg_atomic_read_u32(&buf_hdr->state) & BM_TAG_VALID);
+		Assert(pg_atomic_read_u64(&buf_hdr->state) & BM_TAG_VALID);
 
 		if (i < operation->nblocks_done)
-			Assert(pg_atomic_read_u32(&buf_hdr->state) & BM_VALID);
+			Assert(pg_atomic_read_u64(&buf_hdr->state) & BM_VALID);
 	}
 #endif
 }
@@ -2083,8 +2083,8 @@ BufferAlloc(SMgrRelation smgr, char relpersistence, ForkNumber forkNum,
 	int			existing_buf_id;
 	Buffer		victim_buffer;
 	BufferDesc *victim_buf_hdr;
-	uint32		victim_buf_state;
-	uint32		set_bits = 0;
+	uint64		victim_buf_state;
+	uint64		set_bits = 0;
 
 	/* Make sure we will have room to remember the buffer pin */
 	ResourceOwnerEnlarge(CurrentResourceOwner);
@@ -2251,7 +2251,7 @@ InvalidateBuffer(BufferDesc *buf)
 	uint32		oldHash;		/* hash value for oldTag */
 	LWLock	   *oldPartitionLock;	/* buffer partition lock for it */
 	uint32		oldFlags;
-	uint32		buf_state;
+	uint64		buf_state;
 
 	/* Save the original buffer tag before dropping the spinlock */
 	oldTag = buf->tag;
@@ -2342,7 +2342,7 @@ retry:
 static bool
 InvalidateVictimBuffer(BufferDesc *buf_hdr)
 {
-	uint32		buf_state;
+	uint64		buf_state;
 	uint32		hash;
 	LWLock	   *partition_lock;
 	BufferTag	tag;
@@ -2402,10 +2402,10 @@ InvalidateVictimBuffer(BufferDesc *buf_hdr)
 
 	LWLockRelease(partition_lock);
 
-	buf_state = pg_atomic_read_u32(&buf_hdr->state);
+	buf_state = pg_atomic_read_u64(&buf_hdr->state);
 	Assert(!(buf_state & (BM_DIRTY | BM_VALID | BM_TAG_VALID)));
 	Assert(BUF_STATE_GET_REFCOUNT(buf_state) > 0);
-	Assert(BUF_STATE_GET_REFCOUNT(pg_atomic_read_u32(&buf_hdr->state)) > 0);
+	Assert(BUF_STATE_GET_REFCOUNT(pg_atomic_read_u64(&buf_hdr->state)) > 0);
 
 	return true;
 }
@@ -2415,7 +2415,7 @@ GetVictimBuffer(BufferAccessStrategy strategy, IOContext io_context)
 {
 	BufferDesc *buf_hdr;
 	Buffer		buf;
-	uint32		buf_state;
+	uint64		buf_state;
 	bool		from_ring;
 
 	/*
@@ -2548,7 +2548,7 @@ again:
 
 	/* a final set of sanity checks */
 #ifdef USE_ASSERT_CHECKING
-	buf_state = pg_atomic_read_u32(&buf_hdr->state);
+	buf_state = pg_atomic_read_u64(&buf_hdr->state);
 
 	Assert(BUF_STATE_GET_REFCOUNT(buf_state) == 1);
 	Assert(!(buf_state & (BM_TAG_VALID | BM_VALID | BM_DIRTY)));
@@ -2839,13 +2839,13 @@ ExtendBufferedRelShared(BufferManagerRelation bmr,
 			 */
 			do
 			{
-				pg_atomic_fetch_and_u32(&existing_hdr->state, ~BM_VALID);
+				pg_atomic_fetch_and_u64(&existing_hdr->state, ~BM_VALID);
 			} while (!StartBufferIO(existing_hdr, true, false));
 		}
 		else
 		{
-			uint32		buf_state;
-			uint32		set_bits = 0;
+			uint64		buf_state;
+			uint64		set_bits = 0;
 
 			buf_state = LockBufHdr(victim_buf_hdr);
 
@@ -3021,7 +3021,7 @@ BufferIsDirty(Buffer buffer)
 		Assert(BufferIsLockedByMeInMode(buffer, BUFFER_LOCK_EXCLUSIVE));
 	}
 
-	return pg_atomic_read_u32(&bufHdr->state) & BM_DIRTY;
+	return pg_atomic_read_u64(&bufHdr->state) & BM_DIRTY;
 }
 
 /*
@@ -3037,8 +3037,8 @@ void
 MarkBufferDirty(Buffer buffer)
 {
 	BufferDesc *bufHdr;
-	uint32		buf_state;
-	uint32		old_buf_state;
+	uint64		buf_state;
+	uint64		old_buf_state;
 
 	if (!BufferIsValid(buffer))
 		elog(ERROR, "bad buffer ID: %d", buffer);
@@ -3058,7 +3058,7 @@ MarkBufferDirty(Buffer buffer)
 	 * NB: We have to wait for the buffer header spinlock to be not held, as
 	 * TerminateBufferIO() relies on the spinlock.
 	 */
-	old_buf_state = pg_atomic_read_u32(&bufHdr->state);
+	old_buf_state = pg_atomic_read_u64(&bufHdr->state);
 	for (;;)
 	{
 		if (old_buf_state & BM_LOCKED)
@@ -3069,7 +3069,7 @@ MarkBufferDirty(Buffer buffer)
 		Assert(BUF_STATE_GET_REFCOUNT(buf_state) > 0);
 		buf_state |= BM_DIRTY | BM_JUST_DIRTIED;
 
-		if (pg_atomic_compare_exchange_u32(&bufHdr->state, &old_buf_state,
+		if (pg_atomic_compare_exchange_u64(&bufHdr->state, &old_buf_state,
 										   buf_state))
 			break;
 	}
@@ -3173,10 +3173,10 @@ PinBuffer(BufferDesc *buf, BufferAccessStrategy strategy,
 
 	if (ref == NULL)
 	{
-		uint32		buf_state;
-		uint32		old_buf_state;
+		uint64		buf_state;
+		uint64		old_buf_state;
 
-		old_buf_state = pg_atomic_read_u32(&buf->state);
+		old_buf_state = pg_atomic_read_u64(&buf->state);
 		for (;;)
 		{
 			if (unlikely(skip_if_not_valid && !(old_buf_state & BM_VALID)))
@@ -3210,7 +3210,7 @@ PinBuffer(BufferDesc *buf, BufferAccessStrategy strategy,
 					buf_state += BUF_USAGECOUNT_ONE;
 			}
 
-			if (pg_atomic_compare_exchange_u32(&buf->state, &old_buf_state,
+			if (pg_atomic_compare_exchange_u64(&buf->state, &old_buf_state,
 											   buf_state))
 			{
 				result = (buf_state & BM_VALID) != 0;
@@ -3237,7 +3237,7 @@ PinBuffer(BufferDesc *buf, BufferAccessStrategy strategy,
 		 * that the buffer page is legitimately non-accessible here.  We
 		 * cannot meddle with that.
 		 */
-		result = (pg_atomic_read_u32(&buf->state) & BM_VALID) != 0;
+		result = (pg_atomic_read_u64(&buf->state) & BM_VALID) != 0;
 
 		Assert(ref->data.refcount > 0);
 		ref->data.refcount++;
@@ -3272,7 +3272,7 @@ PinBuffer(BufferDesc *buf, BufferAccessStrategy strategy,
 static void
 PinBuffer_Locked(BufferDesc *buf)
 {
-	uint32		old_buf_state;
+	uint64		old_buf_state;
 
 	/*
 	 * As explained, We don't expect any preexisting pins. That allows us to
@@ -3284,7 +3284,7 @@ PinBuffer_Locked(BufferDesc *buf)
 	 * Since we hold the buffer spinlock, we can update the buffer state and
 	 * release the lock in one operation.
 	 */
-	old_buf_state = pg_atomic_read_u32(&buf->state);
+	old_buf_state = pg_atomic_read_u64(&buf->state);
 
 	UnlockBufHdrExt(buf, old_buf_state,
 					0, 0, 1);
@@ -3314,7 +3314,7 @@ WakePinCountWaiter(BufferDesc *buf)
 	 * BM_PIN_COUNT_WAITER if it stops waiting for a reason other than this
 	 * backend waking it up.
 	 */
-	uint32		buf_state = LockBufHdr(buf);
+	uint64		buf_state = LockBufHdr(buf);
 
 	if ((buf_state & BM_PIN_COUNT_WAITER) &&
 		BUF_STATE_GET_REFCOUNT(buf_state) == 1)
@@ -3361,7 +3361,7 @@ UnpinBufferNoOwner(BufferDesc *buf)
 	ref->data.refcount--;
 	if (ref->data.refcount == 0)
 	{
-		uint32		old_buf_state;
+		uint64		old_buf_state;
 
 		/*
 		 * Mark buffer non-accessible to Valgrind.
@@ -3379,7 +3379,7 @@ UnpinBufferNoOwner(BufferDesc *buf)
 		Assert(!LWLockHeldByMe(BufferDescriptorGetContentLock(buf)));
 
 		/* decrement the shared reference count */
-		old_buf_state = pg_atomic_fetch_sub_u32(&buf->state, BUF_REFCOUNT_ONE);
+		old_buf_state = pg_atomic_fetch_sub_u64(&buf->state, BUF_REFCOUNT_ONE);
 
 		/* Support LockBufferForCleanup() */
 		if (old_buf_state & BM_PIN_COUNT_WAITER)
@@ -3436,7 +3436,7 @@ TrackNewBufferPin(Buffer buf)
 static void
 BufferSync(int flags)
 {
-	uint32		buf_state;
+	uint64		buf_state;
 	int			buf_id;
 	int			num_to_scan;
 	int			num_spaces;
@@ -3446,7 +3446,7 @@ BufferSync(int flags)
 	Oid			last_tsid;
 	binaryheap *ts_heap;
 	int			i;
-	uint32		mask = BM_DIRTY;
+	uint64		mask = BM_DIRTY;
 	WritebackContext wb_context;
 
 	/*
@@ -3478,7 +3478,7 @@ BufferSync(int flags)
 	for (buf_id = 0; buf_id < NBuffers; buf_id++)
 	{
 		BufferDesc *bufHdr = GetBufferDescriptor(buf_id);
-		uint32		set_bits = 0;
+		uint64		set_bits = 0;
 
 		/*
 		 * Header spinlock is enough to examine BM_DIRTY, see comment in
@@ -3645,7 +3645,7 @@ BufferSync(int flags)
 		 * write the buffer though we didn't need to.  It doesn't seem worth
 		 * guarding against this, though.
 		 */
-		if (pg_atomic_read_u32(&bufHdr->state) & BM_CHECKPOINT_NEEDED)
+		if (pg_atomic_read_u64(&bufHdr->state) & BM_CHECKPOINT_NEEDED)
 		{
 			if (SyncOneBuffer(buf_id, false, &wb_context) & BUF_WRITTEN)
 			{
@@ -4015,7 +4015,7 @@ SyncOneBuffer(int buf_id, bool skip_recently_used, WritebackContext *wb_context)
 {
 	BufferDesc *bufHdr = GetBufferDescriptor(buf_id);
 	int			result = 0;
-	uint32		buf_state;
+	uint64		buf_state;
 	BufferTag	tag;
 
 	/* Make sure we can handle the pin */
@@ -4264,7 +4264,7 @@ DebugPrintBufferRefcount(Buffer buffer)
 	int32		loccount;
 	char	   *result;
 	ProcNumber	backend;
-	uint32		buf_state;
+	uint64		buf_state;
 
 	Assert(BufferIsValid(buffer));
 	if (BufferIsLocal(buffer))
@@ -4281,9 +4281,9 @@ DebugPrintBufferRefcount(Buffer buffer)
 	}
 
 	/* theoretically we should lock the bufHdr here */
-	buf_state = pg_atomic_read_u32(&buf->state);
+	buf_state = pg_atomic_read_u64(&buf->state);
 
-	result = psprintf("[%03d] (rel=%s, blockNum=%u, flags=0x%x, refcount=%u %d)",
+	result = psprintf("[%03d] (rel=%s, blockNum=%u, flags=0x%" PRIx64 ", refcount=%u %d)",
 					  buffer,
 					  relpathbackend(BufTagGetRelFileLocator(&buf->tag), backend,
 									 BufTagGetForkNum(&buf->tag)).str,
@@ -4383,7 +4383,7 @@ FlushBuffer(BufferDesc *buf, SMgrRelation reln, IOObject io_object,
 	instr_time	io_start;
 	Block		bufBlock;
 	char	   *bufToWrite;
-	uint32		buf_state;
+	uint64		buf_state;
 
 	/*
 	 * Try to start an I/O operation.  If StartBufferIO returns false, then
@@ -4581,7 +4581,7 @@ BufferIsPermanent(Buffer buffer)
 	 * not random garbage.
 	 */
 	bufHdr = GetBufferDescriptor(buffer - 1);
-	return (pg_atomic_read_u32(&bufHdr->state) & BM_PERMANENT) != 0;
+	return (pg_atomic_read_u64(&bufHdr->state) & BM_PERMANENT) != 0;
 }
 
 /*
@@ -5044,11 +5044,11 @@ FlushRelationBuffers(Relation rel)
 	{
 		for (i = 0; i < NLocBuffer; i++)
 		{
-			uint32		buf_state;
+			uint64		buf_state;
 
 			bufHdr = GetLocalBufferDescriptor(i);
 			if (BufTagMatchesRelFileLocator(&bufHdr->tag, &rel->rd_locator) &&
-				((buf_state = pg_atomic_read_u32(&bufHdr->state)) &
+				((buf_state = pg_atomic_read_u64(&bufHdr->state)) &
 				 (BM_VALID | BM_DIRTY)) == (BM_VALID | BM_DIRTY))
 			{
 				ErrorContextCallback errcallback;
@@ -5084,7 +5084,7 @@ FlushRelationBuffers(Relation rel)
 
 	for (i = 0; i < NBuffers; i++)
 	{
-		uint32		buf_state;
+		uint64		buf_state;
 
 		bufHdr = GetBufferDescriptor(i);
 
@@ -5156,7 +5156,7 @@ FlushRelationsAllBuffers(SMgrRelation *smgrs, int nrels)
 	{
 		SMgrSortArray *srelent = NULL;
 		BufferDesc *bufHdr = GetBufferDescriptor(i);
-		uint32		buf_state;
+		uint64		buf_state;
 
 		/*
 		 * As in DropRelationBuffers, an unlocked precheck should be safe and
@@ -5405,7 +5405,7 @@ FlushDatabaseBuffers(Oid dbid)
 
 	for (i = 0; i < NBuffers; i++)
 	{
-		uint32		buf_state;
+		uint64		buf_state;
 
 		bufHdr = GetBufferDescriptor(i);
 
@@ -5553,13 +5553,13 @@ MarkBufferDirtyHint(Buffer buffer, bool buffer_std)
 	 * is only intended to be used in cases where failing to write out the
 	 * data would be harmless anyway, it doesn't really matter.
 	 */
-	if ((pg_atomic_read_u32(&bufHdr->state) & (BM_DIRTY | BM_JUST_DIRTIED)) !=
+	if ((pg_atomic_read_u64(&bufHdr->state) & (BM_DIRTY | BM_JUST_DIRTIED)) !=
 		(BM_DIRTY | BM_JUST_DIRTIED))
 	{
 		XLogRecPtr	lsn = InvalidXLogRecPtr;
 		bool		dirtied = false;
 		bool		delayChkptFlags = false;
-		uint32		buf_state;
+		uint64		buf_state;
 
 		/*
 		 * If we need to protect hint bit updates from torn writes, WAL-log a
@@ -5571,7 +5571,7 @@ MarkBufferDirtyHint(Buffer buffer, bool buffer_std)
 		 * when we call XLogInsert() since the value changes dynamically.
 		 */
 		if (XLogHintBitIsNeeded() &&
-			(pg_atomic_read_u32(&bufHdr->state) & BM_PERMANENT))
+			(pg_atomic_read_u64(&bufHdr->state) & BM_PERMANENT))
 		{
 			/*
 			 * If we must not write WAL, due to a relfilelocator-specific
@@ -5671,8 +5671,8 @@ UnlockBuffers(void)
 
 	if (buf)
 	{
-		uint32		buf_state;
-		uint32		unset_bits = 0;
+		uint64		buf_state;
+		uint64		unset_bits = 0;
 
 		buf_state = LockBufHdr(buf);
 
@@ -5803,8 +5803,8 @@ LockBufferForCleanup(Buffer buffer)
 
 	for (;;)
 	{
-		uint32		buf_state;
-		uint32		unset_bits = 0;
+		uint64		buf_state;
+		uint64		unset_bits = 0;
 
 		/* Try to acquire lock */
 		LockBuffer(buffer, BUFFER_LOCK_EXCLUSIVE);
@@ -5952,7 +5952,7 @@ bool
 ConditionalLockBufferForCleanup(Buffer buffer)
 {
 	BufferDesc *bufHdr;
-	uint32		buf_state,
+	uint64		buf_state,
 				refcount;
 
 	Assert(BufferIsValid(buffer));
@@ -6010,7 +6010,7 @@ bool
 IsBufferCleanupOK(Buffer buffer)
 {
 	BufferDesc *bufHdr;
-	uint32		buf_state;
+	uint64		buf_state;
 
 	Assert(BufferIsValid(buffer));
 
@@ -6066,7 +6066,7 @@ WaitIO(BufferDesc *buf)
 	ConditionVariablePrepareToSleep(cv);
 	for (;;)
 	{
-		uint32		buf_state;
+		uint64		buf_state;
 		PgAioWaitRef iow;
 
 		/*
@@ -6140,7 +6140,7 @@ WaitIO(BufferDesc *buf)
 bool
 StartBufferIO(BufferDesc *buf, bool forInput, bool nowait)
 {
-	uint32		buf_state;
+	uint64		buf_state;
 
 	ResourceOwnerEnlarge(CurrentResourceOwner);
 
@@ -6196,11 +6196,11 @@ StartBufferIO(BufferDesc *buf, bool forInput, bool nowait)
  * is being released)
  */
 void
-TerminateBufferIO(BufferDesc *buf, bool clear_dirty, uint32 set_flag_bits,
+TerminateBufferIO(BufferDesc *buf, bool clear_dirty, uint64 set_flag_bits,
 				  bool forget_owner, bool release_aio)
 {
-	uint32		buf_state;
-	uint32		unset_flag_bits = 0;
+	uint64		buf_state;
+	uint64		unset_flag_bits = 0;
 	int			refcount_change = 0;
 
 	buf_state = LockBufHdr(buf);
@@ -6261,7 +6261,7 @@ static void
 AbortBufferIO(Buffer buffer)
 {
 	BufferDesc *buf_hdr = GetBufferDescriptor(buffer - 1);
-	uint32		buf_state;
+	uint64		buf_state;
 
 	buf_state = LockBufHdr(buf_hdr);
 	Assert(buf_state & (BM_IO_IN_PROGRESS | BM_TAG_VALID));
@@ -6355,10 +6355,10 @@ rlocator_comparator(const void *p1, const void *p2)
 /*
  * Lock buffer header - set BM_LOCKED in buffer state.
  */
-uint32
+uint64
 LockBufHdr(BufferDesc *desc)
 {
-	uint32		old_buf_state;
+	uint64		old_buf_state;
 
 	Assert(!BufferIsLocal(BufferDescriptorGetBuffer(desc)));
 
@@ -6369,7 +6369,7 @@ LockBufHdr(BufferDesc *desc)
 		 * the spin-delay infrastructure. The work necessary for that shows up
 		 * in profiles and is rarely necessary.
 		 */
-		old_buf_state = pg_atomic_fetch_or_u32(&desc->state, BM_LOCKED);
+		old_buf_state = pg_atomic_fetch_or_u64(&desc->state, BM_LOCKED);
 		if (likely(!(old_buf_state & BM_LOCKED)))
 			break;				/* got lock */
 
@@ -6382,7 +6382,7 @@ LockBufHdr(BufferDesc *desc)
 			while (old_buf_state & BM_LOCKED)
 			{
 				perform_spin_delay(&delayStatus);
-				old_buf_state = pg_atomic_read_u32(&desc->state);
+				old_buf_state = pg_atomic_read_u64(&desc->state);
 			}
 			finish_spin_delay(&delayStatus);
 		}
@@ -6403,20 +6403,20 @@ LockBufHdr(BufferDesc *desc)
  * Obviously the buffer could be locked by the time the value is returned, so
  * this is primarily useful in CAS style loops.
  */
-pg_noinline uint32
+pg_noinline uint64
 WaitBufHdrUnlocked(BufferDesc *buf)
 {
 	SpinDelayStatus delayStatus;
-	uint32		buf_state;
+	uint64		buf_state;
 
 	init_local_spin_delay(&delayStatus);
 
-	buf_state = pg_atomic_read_u32(&buf->state);
+	buf_state = pg_atomic_read_u64(&buf->state);
 
 	while (buf_state & BM_LOCKED)
 	{
 		perform_spin_delay(&delayStatus);
-		buf_state = pg_atomic_read_u32(&buf->state);
+		buf_state = pg_atomic_read_u64(&buf->state);
 	}
 
 	finish_spin_delay(&delayStatus);
@@ -6704,12 +6704,12 @@ ResOwnerPrintBufferPin(Datum res)
 static bool
 EvictUnpinnedBufferInternal(BufferDesc *desc, bool *buffer_flushed)
 {
-	uint32		buf_state;
+	uint64		buf_state;
 	bool		result;
 
 	*buffer_flushed = false;
 
-	buf_state = pg_atomic_read_u32(&(desc->state));
+	buf_state = pg_atomic_read_u64(&(desc->state));
 	Assert(buf_state & BM_LOCKED);
 
 	if ((buf_state & BM_VALID) == 0)
@@ -6803,12 +6803,12 @@ EvictAllUnpinnedBuffers(int32 *buffers_evicted, int32 *buffers_flushed,
 	for (int buf = 1; buf <= NBuffers; buf++)
 	{
 		BufferDesc *desc = GetBufferDescriptor(buf - 1);
-		uint32		buf_state;
+		uint64		buf_state;
 		bool		buffer_flushed;
 
 		CHECK_FOR_INTERRUPTS();
 
-		buf_state = pg_atomic_read_u32(&desc->state);
+		buf_state = pg_atomic_read_u64(&desc->state);
 		if (!(buf_state & BM_VALID))
 			continue;
 
@@ -6855,7 +6855,7 @@ EvictRelUnpinnedBuffers(Relation rel, int32 *buffers_evicted,
 	for (int buf = 1; buf <= NBuffers; buf++)
 	{
 		BufferDesc *desc = GetBufferDescriptor(buf - 1);
-		uint32		buf_state = pg_atomic_read_u32(&(desc->state));
+		uint64		buf_state = pg_atomic_read_u64(&(desc->state));
 		bool		buffer_flushed;
 
 		CHECK_FOR_INTERRUPTS();
@@ -6897,12 +6897,12 @@ static bool
 MarkDirtyUnpinnedBufferInternal(Buffer buf, BufferDesc *desc,
 								bool *buffer_already_dirty)
 {
-	uint32		buf_state;
+	uint64		buf_state;
 	bool		result = false;
 
 	*buffer_already_dirty = false;
 
-	buf_state = pg_atomic_read_u32(&(desc->state));
+	buf_state = pg_atomic_read_u64(&(desc->state));
 	Assert(buf_state & BM_LOCKED);
 
 	if ((buf_state & BM_VALID) == 0)
@@ -7000,7 +7000,7 @@ MarkDirtyRelUnpinnedBuffers(Relation rel,
 	for (int buf = 1; buf <= NBuffers; buf++)
 	{
 		BufferDesc *desc = GetBufferDescriptor(buf - 1);
-		uint32		buf_state = pg_atomic_read_u32(&(desc->state));
+		uint64		buf_state = pg_atomic_read_u64(&(desc->state));
 		bool		buffer_already_dirty;
 
 		CHECK_FOR_INTERRUPTS();
@@ -7054,12 +7054,12 @@ MarkDirtyAllUnpinnedBuffers(int32 *buffers_dirtied,
 	for (int buf = 1; buf <= NBuffers; buf++)
 	{
 		BufferDesc *desc = GetBufferDescriptor(buf - 1);
-		uint32		buf_state;
+		uint64		buf_state;
 		bool		buffer_already_dirty;
 
 		CHECK_FOR_INTERRUPTS();
 
-		buf_state = pg_atomic_read_u32(&desc->state);
+		buf_state = pg_atomic_read_u64(&desc->state);
 		if (!(buf_state & BM_VALID))
 			continue;
 
@@ -7110,7 +7110,7 @@ buffer_stage_common(PgAioHandle *ioh, bool is_write, bool is_temp)
 		BufferDesc *buf_hdr = is_temp ?
 			GetLocalBufferDescriptor(-buffer - 1)
 			: GetBufferDescriptor(buffer - 1);
-		uint32		buf_state;
+		uint64		buf_state;
 
 		/*
 		 * Check that all the buffers are actually ones that could conceivably
@@ -7128,7 +7128,7 @@ buffer_stage_common(PgAioHandle *ioh, bool is_write, bool is_temp)
 		}
 
 		if (is_temp)
-			buf_state = pg_atomic_read_u32(&buf_hdr->state);
+			buf_state = pg_atomic_read_u64(&buf_hdr->state);
 		else
 			buf_state = LockBufHdr(buf_hdr);
 
@@ -7166,7 +7166,7 @@ buffer_stage_common(PgAioHandle *ioh, bool is_write, bool is_temp)
 		if (is_temp)
 		{
 			buf_state += BUF_REFCOUNT_ONE;
-			pg_atomic_unlocked_write_u32(&buf_hdr->state, buf_state);
+			pg_atomic_unlocked_write_u64(&buf_hdr->state, buf_state);
 		}
 		else
 			UnlockBufHdrExt(buf_hdr, buf_state, 0, 0, 1);
@@ -7352,13 +7352,13 @@ buffer_readv_complete_one(PgAioTargetData *td, uint8 buf_off, Buffer buffer,
 		: GetBufferDescriptor(buffer - 1);
 	BufferTag	tag = buf_hdr->tag;
 	char	   *bufdata = BufferGetBlock(buffer);
-	uint32		set_flag_bits;
+	uint64		set_flag_bits;
 	int			piv_flags;
 
 	/* check that the buffer is in the expected state for a read */
 #ifdef USE_ASSERT_CHECKING
 	{
-		uint32		buf_state = pg_atomic_read_u32(&buf_hdr->state);
+		uint64		buf_state = pg_atomic_read_u64(&buf_hdr->state);
 
 		Assert(buf_state & BM_TAG_VALID);
 		Assert(!(buf_state & BM_VALID));
diff --git a/src/backend/storage/buffer/freelist.c b/src/backend/storage/buffer/freelist.c
index 9a93fb335fc..b7687836188 100644
--- a/src/backend/storage/buffer/freelist.c
+++ b/src/backend/storage/buffer/freelist.c
@@ -86,7 +86,7 @@ typedef struct BufferAccessStrategyData
 
 /* Prototypes for internal functions */
 static BufferDesc *GetBufferFromRing(BufferAccessStrategy strategy,
-									 uint32 *buf_state);
+									 uint64 *buf_state);
 static void AddBufferToRing(BufferAccessStrategy strategy,
 							BufferDesc *buf);
 
@@ -171,7 +171,7 @@ ClockSweepTick(void)
  *	before returning.
  */
 BufferDesc *
-StrategyGetBuffer(BufferAccessStrategy strategy, uint32 *buf_state, bool *from_ring)
+StrategyGetBuffer(BufferAccessStrategy strategy, uint64 *buf_state, bool *from_ring)
 {
 	BufferDesc *buf;
 	int			bgwprocno;
@@ -230,8 +230,8 @@ StrategyGetBuffer(BufferAccessStrategy strategy, uint32 *buf_state, bool *from_r
 	trycounter = NBuffers;
 	for (;;)
 	{
-		uint32		old_buf_state;
-		uint32		local_buf_state;
+		uint64		old_buf_state;
+		uint64		local_buf_state;
 
 		buf = GetBufferDescriptor(ClockSweepTick());
 
@@ -239,7 +239,7 @@ StrategyGetBuffer(BufferAccessStrategy strategy, uint32 *buf_state, bool *from_r
 		 * Check whether the buffer can be used and pin it if so. Do this
 		 * using a CAS loop, to avoid having to lock the buffer header.
 		 */
-		old_buf_state = pg_atomic_read_u32(&buf->state);
+		old_buf_state = pg_atomic_read_u64(&buf->state);
 		for (;;)
 		{
 			local_buf_state = old_buf_state;
@@ -277,7 +277,7 @@ StrategyGetBuffer(BufferAccessStrategy strategy, uint32 *buf_state, bool *from_r
 			{
 				local_buf_state -= BUF_USAGECOUNT_ONE;
 
-				if (pg_atomic_compare_exchange_u32(&buf->state, &old_buf_state,
+				if (pg_atomic_compare_exchange_u64(&buf->state, &old_buf_state,
 												   local_buf_state))
 				{
 					trycounter = NBuffers;
@@ -289,7 +289,7 @@ StrategyGetBuffer(BufferAccessStrategy strategy, uint32 *buf_state, bool *from_r
 				/* pin the buffer if the CAS succeeds */
 				local_buf_state += BUF_REFCOUNT_ONE;
 
-				if (pg_atomic_compare_exchange_u32(&buf->state, &old_buf_state,
+				if (pg_atomic_compare_exchange_u64(&buf->state, &old_buf_state,
 												   local_buf_state))
 				{
 					/* Found a usable buffer */
@@ -655,12 +655,12 @@ FreeAccessStrategy(BufferAccessStrategy strategy)
  * returning.
  */
 static BufferDesc *
-GetBufferFromRing(BufferAccessStrategy strategy, uint32 *buf_state)
+GetBufferFromRing(BufferAccessStrategy strategy, uint64 *buf_state)
 {
 	BufferDesc *buf;
 	Buffer		bufnum;
-	uint32		old_buf_state;
-	uint32		local_buf_state;	/* to avoid repeated (de-)referencing */
+	uint64		old_buf_state;
+	uint64		local_buf_state;	/* to avoid repeated (de-)referencing */
 
 
 	/* Advance to next ring slot */
@@ -682,7 +682,7 @@ GetBufferFromRing(BufferAccessStrategy strategy, uint32 *buf_state)
 	 * Check whether the buffer can be used and pin it if so. Do this using a
 	 * CAS loop, to avoid having to lock the buffer header.
 	 */
-	old_buf_state = pg_atomic_read_u32(&buf->state);
+	old_buf_state = pg_atomic_read_u64(&buf->state);
 	for (;;)
 	{
 		local_buf_state = old_buf_state;
@@ -710,7 +710,7 @@ GetBufferFromRing(BufferAccessStrategy strategy, uint32 *buf_state)
 		/* pin the buffer if the CAS succeeds */
 		local_buf_state += BUF_REFCOUNT_ONE;
 
-		if (pg_atomic_compare_exchange_u32(&buf->state, &old_buf_state,
+		if (pg_atomic_compare_exchange_u64(&buf->state, &old_buf_state,
 										   local_buf_state))
 		{
 			*buf_state = local_buf_state;
diff --git a/src/backend/storage/buffer/localbuf.c b/src/backend/storage/buffer/localbuf.c
index f6e2b1aa288..04a540379a2 100644
--- a/src/backend/storage/buffer/localbuf.c
+++ b/src/backend/storage/buffer/localbuf.c
@@ -148,7 +148,7 @@ LocalBufferAlloc(SMgrRelation smgr, ForkNumber forkNum, BlockNumber blockNum,
 	}
 	else
 	{
-		uint32		buf_state;
+		uint64		buf_state;
 
 		victim_buffer = GetLocalVictimBuffer();
 		bufid = -victim_buffer - 1;
@@ -165,10 +165,10 @@ LocalBufferAlloc(SMgrRelation smgr, ForkNumber forkNum, BlockNumber blockNum,
 		 */
 		bufHdr->tag = newTag;
 
-		buf_state = pg_atomic_read_u32(&bufHdr->state);
+		buf_state = pg_atomic_read_u64(&bufHdr->state);
 		buf_state &= ~(BUF_FLAG_MASK | BUF_USAGECOUNT_MASK);
 		buf_state |= BM_TAG_VALID | BUF_USAGECOUNT_ONE;
-		pg_atomic_unlocked_write_u32(&bufHdr->state, buf_state);
+		pg_atomic_unlocked_write_u64(&bufHdr->state, buf_state);
 
 		*foundPtr = false;
 	}
@@ -245,12 +245,12 @@ GetLocalVictimBuffer(void)
 
 		if (LocalRefCount[victim_bufid] == 0)
 		{
-			uint32		buf_state = pg_atomic_read_u32(&bufHdr->state);
+			uint64		buf_state = pg_atomic_read_u64(&bufHdr->state);
 
 			if (BUF_STATE_GET_USAGECOUNT(buf_state) > 0)
 			{
 				buf_state -= BUF_USAGECOUNT_ONE;
-				pg_atomic_unlocked_write_u32(&bufHdr->state, buf_state);
+				pg_atomic_unlocked_write_u64(&bufHdr->state, buf_state);
 				trycounter = NLocBuffer;
 			}
 			else if (BUF_STATE_GET_REFCOUNT(buf_state) > 0)
@@ -286,13 +286,13 @@ GetLocalVictimBuffer(void)
 	 * this buffer is not referenced but it might still be dirty. if that's
 	 * the case, write it out before reusing it!
 	 */
-	if (pg_atomic_read_u32(&bufHdr->state) & BM_DIRTY)
+	if (pg_atomic_read_u64(&bufHdr->state) & BM_DIRTY)
 		FlushLocalBuffer(bufHdr, NULL);
 
 	/*
 	 * Remove the victim buffer from the hashtable and mark as invalid.
 	 */
-	if (pg_atomic_read_u32(&bufHdr->state) & BM_TAG_VALID)
+	if (pg_atomic_read_u64(&bufHdr->state) & BM_TAG_VALID)
 	{
 		InvalidateLocalBuffer(bufHdr, false);
 
@@ -417,7 +417,7 @@ ExtendBufferedRelLocal(BufferManagerRelation bmr,
 		if (found)
 		{
 			BufferDesc *existing_hdr;
-			uint32		buf_state;
+			uint64		buf_state;
 
 			UnpinLocalBuffer(BufferDescriptorGetBuffer(victim_buf_hdr));
 
@@ -428,18 +428,18 @@ ExtendBufferedRelLocal(BufferManagerRelation bmr,
 			/*
 			 * Clear the BM_VALID bit, do StartLocalBufferIO() and proceed.
 			 */
-			buf_state = pg_atomic_read_u32(&existing_hdr->state);
+			buf_state = pg_atomic_read_u64(&existing_hdr->state);
 			Assert(buf_state & BM_TAG_VALID);
 			Assert(!(buf_state & BM_DIRTY));
 			buf_state &= ~BM_VALID;
-			pg_atomic_unlocked_write_u32(&existing_hdr->state, buf_state);
+			pg_atomic_unlocked_write_u64(&existing_hdr->state, buf_state);
 
 			/* no need to loop for local buffers */
 			StartLocalBufferIO(existing_hdr, true, false);
 		}
 		else
 		{
-			uint32		buf_state = pg_atomic_read_u32(&victim_buf_hdr->state);
+			uint64		buf_state = pg_atomic_read_u64(&victim_buf_hdr->state);
 
 			Assert(!(buf_state & (BM_VALID | BM_TAG_VALID | BM_DIRTY | BM_JUST_DIRTIED)));
 
@@ -447,7 +447,7 @@ ExtendBufferedRelLocal(BufferManagerRelation bmr,
 
 			buf_state |= BM_TAG_VALID | BUF_USAGECOUNT_ONE;
 
-			pg_atomic_unlocked_write_u32(&victim_buf_hdr->state, buf_state);
+			pg_atomic_unlocked_write_u64(&victim_buf_hdr->state, buf_state);
 
 			hresult->id = victim_buf_id;
 
@@ -467,13 +467,13 @@ ExtendBufferedRelLocal(BufferManagerRelation bmr,
 	{
 		Buffer		buf = buffers[i];
 		BufferDesc *buf_hdr;
-		uint32		buf_state;
+		uint64		buf_state;
 
 		buf_hdr = GetLocalBufferDescriptor(-buf - 1);
 
-		buf_state = pg_atomic_read_u32(&buf_hdr->state);
+		buf_state = pg_atomic_read_u64(&buf_hdr->state);
 		buf_state |= BM_VALID;
-		pg_atomic_unlocked_write_u32(&buf_hdr->state, buf_state);
+		pg_atomic_unlocked_write_u64(&buf_hdr->state, buf_state);
 	}
 
 	*extended_by = extend_by;
@@ -492,7 +492,7 @@ MarkLocalBufferDirty(Buffer buffer)
 {
 	int			bufid;
 	BufferDesc *bufHdr;
-	uint32		buf_state;
+	uint64		buf_state;
 
 	Assert(BufferIsLocal(buffer));
 
@@ -506,14 +506,14 @@ MarkLocalBufferDirty(Buffer buffer)
 
 	bufHdr = GetLocalBufferDescriptor(bufid);
 
-	buf_state = pg_atomic_read_u32(&bufHdr->state);
+	buf_state = pg_atomic_read_u64(&bufHdr->state);
 
 	if (!(buf_state & BM_DIRTY))
 		pgBufferUsage.local_blks_dirtied++;
 
 	buf_state |= BM_DIRTY;
 
-	pg_atomic_unlocked_write_u32(&bufHdr->state, buf_state);
+	pg_atomic_unlocked_write_u64(&bufHdr->state, buf_state);
 }
 
 /*
@@ -522,7 +522,7 @@ MarkLocalBufferDirty(Buffer buffer)
 bool
 StartLocalBufferIO(BufferDesc *bufHdr, bool forInput, bool nowait)
 {
-	uint32		buf_state;
+	uint64		buf_state;
 
 	/*
 	 * With AIO the buffer could have IO in progress, e.g. when there are two
@@ -542,7 +542,7 @@ StartLocalBufferIO(BufferDesc *bufHdr, bool forInput, bool nowait)
 	/* Once we get here, there is definitely no I/O active on this buffer */
 
 	/* Check if someone else already did the I/O */
-	buf_state = pg_atomic_read_u32(&bufHdr->state);
+	buf_state = pg_atomic_read_u64(&bufHdr->state);
 	if (forInput ? (buf_state & BM_VALID) : !(buf_state & BM_DIRTY))
 	{
 		return false;
@@ -559,11 +559,11 @@ StartLocalBufferIO(BufferDesc *bufHdr, bool forInput, bool nowait)
  * Like TerminateBufferIO, but for local buffers
  */
 void
-TerminateLocalBufferIO(BufferDesc *bufHdr, bool clear_dirty, uint32 set_flag_bits,
+TerminateLocalBufferIO(BufferDesc *bufHdr, bool clear_dirty, uint64 set_flag_bits,
 					   bool release_aio)
 {
 	/* Only need to adjust flags */
-	uint32		buf_state = pg_atomic_read_u32(&bufHdr->state);
+	uint64		buf_state = pg_atomic_read_u64(&bufHdr->state);
 
 	/* BM_IO_IN_PROGRESS isn't currently used for local buffers */
 
@@ -582,7 +582,7 @@ TerminateLocalBufferIO(BufferDesc *bufHdr, bool clear_dirty, uint32 set_flag_bit
 	}
 
 	buf_state |= set_flag_bits;
-	pg_atomic_unlocked_write_u32(&bufHdr->state, buf_state);
+	pg_atomic_unlocked_write_u64(&bufHdr->state, buf_state);
 
 	/* local buffers don't track IO using resowners */
 
@@ -606,7 +606,7 @@ InvalidateLocalBuffer(BufferDesc *bufHdr, bool check_unreferenced)
 {
 	Buffer		buffer = BufferDescriptorGetBuffer(bufHdr);
 	int			bufid = -buffer - 1;
-	uint32		buf_state;
+	uint64		buf_state;
 	LocalBufferLookupEnt *hresult;
 
 	/*
@@ -622,7 +622,7 @@ InvalidateLocalBuffer(BufferDesc *bufHdr, bool check_unreferenced)
 		Assert(!pgaio_wref_valid(&bufHdr->io_wref));
 	}
 
-	buf_state = pg_atomic_read_u32(&bufHdr->state);
+	buf_state = pg_atomic_read_u64(&bufHdr->state);
 
 	/*
 	 * We need to test not just LocalRefCount[bufid] but also the BufferDesc
@@ -647,7 +647,7 @@ InvalidateLocalBuffer(BufferDesc *bufHdr, bool check_unreferenced)
 	ClearBufferTag(&bufHdr->tag);
 	buf_state &= ~BUF_FLAG_MASK;
 	buf_state &= ~BUF_USAGECOUNT_MASK;
-	pg_atomic_unlocked_write_u32(&bufHdr->state, buf_state);
+	pg_atomic_unlocked_write_u64(&bufHdr->state, buf_state);
 }
 
 /*
@@ -671,9 +671,9 @@ DropRelationLocalBuffers(RelFileLocator rlocator, ForkNumber *forkNum,
 	for (i = 0; i < NLocBuffer; i++)
 	{
 		BufferDesc *bufHdr = GetLocalBufferDescriptor(i);
-		uint32		buf_state;
+		uint64		buf_state;
 
-		buf_state = pg_atomic_read_u32(&bufHdr->state);
+		buf_state = pg_atomic_read_u64(&bufHdr->state);
 
 		if (!(buf_state & BM_TAG_VALID) ||
 			!BufTagMatchesRelFileLocator(&bufHdr->tag, &rlocator))
@@ -706,9 +706,9 @@ DropRelationAllLocalBuffers(RelFileLocator rlocator)
 	for (i = 0; i < NLocBuffer; i++)
 	{
 		BufferDesc *bufHdr = GetLocalBufferDescriptor(i);
-		uint32		buf_state;
+		uint64		buf_state;
 
-		buf_state = pg_atomic_read_u32(&bufHdr->state);
+		buf_state = pg_atomic_read_u64(&bufHdr->state);
 
 		if ((buf_state & BM_TAG_VALID) &&
 			BufTagMatchesRelFileLocator(&bufHdr->tag, &rlocator))
@@ -804,11 +804,11 @@ InitLocalBuffers(void)
 bool
 PinLocalBuffer(BufferDesc *buf_hdr, bool adjust_usagecount)
 {
-	uint32		buf_state;
+	uint64		buf_state;
 	Buffer		buffer = BufferDescriptorGetBuffer(buf_hdr);
 	int			bufid = -buffer - 1;
 
-	buf_state = pg_atomic_read_u32(&buf_hdr->state);
+	buf_state = pg_atomic_read_u64(&buf_hdr->state);
 
 	if (LocalRefCount[bufid] == 0)
 	{
@@ -819,7 +819,7 @@ PinLocalBuffer(BufferDesc *buf_hdr, bool adjust_usagecount)
 		{
 			buf_state += BUF_USAGECOUNT_ONE;
 		}
-		pg_atomic_unlocked_write_u32(&buf_hdr->state, buf_state);
+		pg_atomic_unlocked_write_u64(&buf_hdr->state, buf_state);
 
 		/*
 		 * See comment in PinBuffer().
@@ -856,14 +856,14 @@ UnpinLocalBufferNoOwner(Buffer buffer)
 	if (--LocalRefCount[buffid] == 0)
 	{
 		BufferDesc *buf_hdr = GetLocalBufferDescriptor(buffid);
-		uint32		buf_state;
+		uint64		buf_state;
 
 		NLocalPinnedBuffers--;
 
-		buf_state = pg_atomic_read_u32(&buf_hdr->state);
+		buf_state = pg_atomic_read_u64(&buf_hdr->state);
 		Assert(BUF_STATE_GET_REFCOUNT(buf_state) > 0);
 		buf_state -= BUF_REFCOUNT_ONE;
-		pg_atomic_unlocked_write_u32(&buf_hdr->state, buf_state);
+		pg_atomic_unlocked_write_u64(&buf_hdr->state, buf_state);
 
 		/* see comment in UnpinBufferNoOwner */
 		VALGRIND_MAKE_MEM_NOACCESS(LocalBufHdrGetBlock(buf_hdr), BLCKSZ);
diff --git a/contrib/pg_buffercache/pg_buffercache_pages.c b/contrib/pg_buffercache/pg_buffercache_pages.c
index b682dca658b..dcba3fb5473 100644
--- a/contrib/pg_buffercache/pg_buffercache_pages.c
+++ b/contrib/pg_buffercache/pg_buffercache_pages.c
@@ -199,7 +199,7 @@ pg_buffercache_pages(PG_FUNCTION_ARGS)
 		for (i = 0; i < NBuffers; i++)
 		{
 			BufferDesc *bufHdr;
-			uint32		buf_state;
+			uint64		buf_state;
 
 			CHECK_FOR_INTERRUPTS();
 
@@ -615,7 +615,7 @@ pg_buffercache_summary(PG_FUNCTION_ARGS)
 	for (int i = 0; i < NBuffers; i++)
 	{
 		BufferDesc *bufHdr;
-		uint32		buf_state;
+		uint64		buf_state;
 
 		CHECK_FOR_INTERRUPTS();
 
@@ -626,7 +626,7 @@ pg_buffercache_summary(PG_FUNCTION_ARGS)
 		 * noticeably increase the cost of the function.
 		 */
 		bufHdr = GetBufferDescriptor(i);
-		buf_state = pg_atomic_read_u32(&bufHdr->state);
+		buf_state = pg_atomic_read_u64(&bufHdr->state);
 
 		if (buf_state & BM_VALID)
 		{
@@ -676,7 +676,7 @@ pg_buffercache_usage_counts(PG_FUNCTION_ARGS)
 	for (int i = 0; i < NBuffers; i++)
 	{
 		BufferDesc *bufHdr = GetBufferDescriptor(i);
-		uint32		buf_state = pg_atomic_read_u32(&bufHdr->state);
+		uint64		buf_state = pg_atomic_read_u64(&bufHdr->state);
 		int			usage_count;
 
 		CHECK_FOR_INTERRUPTS();
diff --git a/contrib/pg_prewarm/autoprewarm.c b/contrib/pg_prewarm/autoprewarm.c
index 3ca7d2ed772..89e187425cc 100644
--- a/contrib/pg_prewarm/autoprewarm.c
+++ b/contrib/pg_prewarm/autoprewarm.c
@@ -703,7 +703,7 @@ apw_dump_now(bool is_bgworker, bool dump_unlogged)
 
 	for (num_blocks = 0, i = 0; i < NBuffers; i++)
 	{
-		uint32		buf_state;
+		uint64		buf_state;
 
 		CHECK_FOR_INTERRUPTS();
 
diff --git a/src/test/modules/test_aio/test_aio.c b/src/test/modules/test_aio/test_aio.c
index e046b08f3d5..b1aa8af9ec0 100644
--- a/src/test/modules/test_aio/test_aio.c
+++ b/src/test/modules/test_aio/test_aio.c
@@ -308,9 +308,9 @@ create_toy_buffer(Relation rel, BlockNumber blkno)
 {
 	Buffer		buf;
 	BufferDesc *buf_hdr;
-	uint32		buf_state;
+	uint64		buf_state;
 	bool		was_pinned = false;
-	uint32		unset_bits = 0;
+	uint64		unset_bits = 0;
 
 	/* place buffer in shared buffers without erroring out */
 	buf = ReadBufferExtended(rel, MAIN_FORKNUM, blkno, RBM_ZERO_AND_LOCK, NULL);
@@ -319,7 +319,7 @@ create_toy_buffer(Relation rel, BlockNumber blkno)
 	if (RelationUsesLocalBuffers(rel))
 	{
 		buf_hdr = GetLocalBufferDescriptor(-buf - 1);
-		buf_state = pg_atomic_read_u32(&buf_hdr->state);
+		buf_state = pg_atomic_read_u64(&buf_hdr->state);
 	}
 	else
 	{
@@ -340,7 +340,7 @@ create_toy_buffer(Relation rel, BlockNumber blkno)
 	if (RelationUsesLocalBuffers(rel))
 	{
 		buf_state &= ~unset_bits;
-		pg_atomic_unlocked_write_u32(&buf_hdr->state, buf_state);
+		pg_atomic_unlocked_write_u64(&buf_hdr->state, buf_state);
 	}
 	else
 	{
@@ -489,7 +489,7 @@ invalidate_rel_block(PG_FUNCTION_ARGS)
 
 			LockBuffer(buf, BUFFER_LOCK_EXCLUSIVE);
 
-			if (pg_atomic_read_u32(&buf_hdr->state) & BM_DIRTY)
+			if (pg_atomic_read_u64(&buf_hdr->state) & BM_DIRTY)
 			{
 				if (BufferIsLocal(buf))
 					FlushLocalBuffer(buf_hdr, NULL);
@@ -572,7 +572,7 @@ buffer_call_terminate_io(PG_FUNCTION_ARGS)
 	bool		io_error = PG_GETARG_BOOL(3);
 	bool		release_aio = PG_GETARG_BOOL(4);
 	bool		clear_dirty = false;
-	uint32		set_flag_bits = 0;
+	uint64		set_flag_bits = 0;
 
 	if (io_error)
 		set_flag_bits |= BM_IO_ERROR;
-- 
2.48.1.76.g4e746b1a31.dirty


--c6wqr3sg4llxfu2u
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
	filename="v11-0002-bufmgr-Implement-buffer-content-locks-independen.patch"



^ permalink  raw  reply  [nested|flat] 129+ messages in thread

* First draft of PG 19 release notes
@ 2026-04-15 01:18  Bruce Momjian <bruce@momjian.us>
  0 siblings, 26 replies; 129+ messages in thread

From: Bruce Momjian @ 2026-04-15 01:18 UTC (permalink / raw)
  To: PostgreSQL-development <pgsql-hackers@lists.postgresql.org>

I have completed the first draft of the PG 19 release notes:

	https://www.postgresql.org/docs/devel/release-19.html

The feature count is 212.  The recent average is 200:

	https://momjian.us/main/writings/pgsql/missing.pdf#page=3

I will create a wiki page to explain my methods used to create this
because, someday, someone else will need to do this.

I am traveling April 19 to May 7, so I might not be able to make quick
adjustments based on feedback.  Another committer can handle them, or
you can wait for me to get to it.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Do not let urgent matters crowd out time for investment in the future.





^ permalink  raw  reply  [nested|flat] 129+ messages in thread

* Re: First draft of PG 19 release notes
@ 2026-04-15 01:53  Bruce Momjian <bruce@momjian.us>
  parent: Bruce Momjian <bruce@momjian.us>
  25 siblings, 0 replies; 129+ messages in thread

From: Bruce Momjian @ 2026-04-15 01:53 UTC (permalink / raw)
  To: PostgreSQL-development <pgsql-hackers@lists.postgresql.org>

On Tue, Apr 14, 2026 at 09:18:57PM -0400, Bruce Momjian wrote:
> I will create a wiki page to explain my methods used to create this
> because, someday, someone else will need to do this.

Done:

	https://wiki.postgresql.org/wiki/Creating_Major_Release_Notes

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Do not let urgent matters crowd out time for investment in the future.





^ permalink  raw  reply  [nested|flat] 129+ messages in thread

* Re: First draft of PG 19 release notes
@ 2026-04-15 02:25  Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>
  parent: Bruce Momjian <bruce@momjian.us>
  25 siblings, 1 reply; 129+ messages in thread

From: Ashutosh Bapat @ 2026-04-15 02:25 UTC (permalink / raw)
  To: Bruce Momjian <bruce@momjian.us>; Heikki Linnakangas <hlinnaka@iki.fi>; +Cc: PostgreSQL-development <pgsql-hackers@lists.postgresql.org>

Hi Bruce,

On Wed, Apr 15, 2026 at 6:49 AM Bruce Momjian <bruce@momjian.us> wrote:
>
> I have completed the first draft of the PG 19 release notes:
>
>         https://www.postgresql.org/docs/devel/release-19.html
>
> The feature count is 212.  The recent average is 200:

One correction:

Add simplified shared memory registration function
ShmemRequestStruct() (Ashutosh Bapat) §

Heikki Linnakangas is the primary author of this commit.

Also, depending upon the availability of space, here's a suggested version:

-- 
Add simplified and improved shared memory registration function
ShmemRequestStruct (Heikki Linnakangas, Ashutosh Bapat)

Allows requesting named shared memory structures during and after
server startup. Functions ShmemInitStruct() and ShmemInitHash() remain
for backward compatibility.
--

-- 
Best Wishes,
Ashutosh Bapat





^ permalink  raw  reply  [nested|flat] 129+ messages in thread

* Re: First draft of PG 19 release notes
@ 2026-04-15 02:29  David Rowley <dgrowleyml@gmail.com>
  parent: Bruce Momjian <bruce@momjian.us>
  25 siblings, 1 reply; 129+ messages in thread

From: David Rowley @ 2026-04-15 02:29 UTC (permalink / raw)
  To: Bruce Momjian <bruce@momjian.us>; +Cc: PostgreSQL-development <pgsql-hackers@lists.postgresql.org>

On Wed, 15 Apr 2026 at 13:19, Bruce Momjian <bruce@momjian.us> wrote:
> I have completed the first draft of the PG 19 release notes:
>
>         https://www.postgresql.org/docs/devel/release-19.html

Many thanks for your efforts here.

"Improve performance of internal row formation (David Rowley)"

It's really deformation, not formation. As far as I know, nothing in
v19 sped up tuple formation.

I also think Nathan's work on autovacuum table prioritisation
(d7965d65f) is worth a mention. There were concerns there that it
might cause trouble for people who (for some reason) get best results
from the previous pg_class-ordered priority. Having something in the
notes about this might help direct someone towards why they're seeing
autovacuum behave differently after upgrading.

David





^ permalink  raw  reply  [nested|flat] 129+ messages in thread

* Re: First draft of PG 19 release notes
@ 2026-04-15 05:27  Peter Smith <smithpb2250@gmail.com>
  parent: Bruce Momjian <bruce@momjian.us>
  25 siblings, 1 reply; 129+ messages in thread

From: Peter Smith @ 2026-04-15 05:27 UTC (permalink / raw)
  To: Bruce Momjian <bruce@momjian.us>; +Cc: PostgreSQL-development <pgsql-hackers@lists.postgresql.org>

Hi,

For this one:
"Allow CREATE/ALTER PUBLICATION to exclude some tables using the
EXCEPT TABLE clause (Vignesh C, Shlok Kyal)"

~

The "EXCEPT TABLE" syntax was later changed to "EXCEPT (TABLE ...)",
so where above says "EXCEPT TABLE clause", probably now that should
just say "EXCEPT clause" same as the documentation.

======
Kind Regards,
Peter Smith.
Fujitsu Australia.





^ permalink  raw  reply  [nested|flat] 129+ messages in thread

* Re: First draft of PG 19 release notes
@ 2026-04-15 08:57  Laurenz Albe <laurenz.albe@cybertec.at>
  parent: Bruce Momjian <bruce@momjian.us>
  25 siblings, 1 reply; 129+ messages in thread

From: Laurenz Albe @ 2026-04-15 08:57 UTC (permalink / raw)
  To: Bruce Momjian <bruce@momjian.us>; PostgreSQL-development <pgsql-hackers@lists.postgresql.org>

On Tue, 2026-04-14 at 21:18 -0400, Bruce Momjian wrote:
> I have completed the first draft of the PG 19 release notes:
> 
> 	https://www.postgresql.org/docs/devel/release-19.html

Thank you!

I noticed a typo:

  Change vacuumdb's --analyze-only option to analyze partitioned tables when now targets are specified

It should probably be "no targets" rather than "now targets".

Yours,
Laurenz Albe





^ permalink  raw  reply  [nested|flat] 129+ messages in thread

* Re: First draft of PG 19 release notes
@ 2026-04-15 11:18  Daniel Gustafsson <daniel@yesql.se>
  parent: Bruce Momjian <bruce@momjian.us>
  25 siblings, 1 reply; 129+ messages in thread

From: Daniel Gustafsson @ 2026-04-15 11:18 UTC (permalink / raw)
  To: Bruce Momjian <bruce@momjian.us>; +Cc: PostgreSQL-development <pgsql-hackers@lists.postgresql.org>

> On 15 Apr 2026, at 03:18, Bruce Momjian <bruce@momjian.us> wrote:
> 
> I have completed the first draft of the PG 19 release notes:

+Allow online enabling and disabling of data checksums (Daniel Gustafsson, Magnus Hagander, Tomas Vondra, Lakshmi N)

This one should only say "Daniel Gustafsson, Magnus Hagander, Tomas Vondra"

--
Daniel Gustafsson






^ permalink  raw  reply  [nested|flat] 129+ messages in thread

* Re: First draft of PG 19 release notes
@ 2026-04-15 14:59  jian he <jian.universality@gmail.com>
  parent: Bruce Momjian <bruce@momjian.us>
  25 siblings, 1 reply; 129+ messages in thread

From: jian he @ 2026-04-15 14:59 UTC (permalink / raw)
  To: Bruce Momjian <bruce@momjian.us>; +Cc: PostgreSQL-development <pgsql-hackers@lists.postgresql.org>

On Wed, Apr 15, 2026 at 9:19 AM Bruce Momjian <bruce@momjian.us> wrote:
>
> I have completed the first draft of the PG 19 release notes:
>
>         https://www.postgresql.org/docs/devel/release-19.html
>

https://git.postgresql.org/cgit/postgresql.git/commit/?id=ecd9288624a1582a732cf86ac5a01475a1ce7815
https://git.postgresql.org/cgit/postgresql.git/commit/?id=4edd6036d69ce42ac1af236f659f20daed65c8d4
Do you think these two are worth adding to the release notes?

"""
Allow COPY TO to output partitioned tables (Jian He, Ajin Cherian) § §
Previously COPY (SELECT ...) has to be used to output partitioned tables.
"""
The second commit uses this feature, so i guess the commit message
needs a slight change.

"""
Improve timing performance measurements (Lukas Fittl, Andres Freund,
David Geier, Lukas Fittl, David Geier) § §
This benefits EXPLAIN (ANALYZE, TIMING) and pg_test_timing, and is
controlled via server variable timing_clock_source.
"""
Duplicated name entry.

"""
Allow IS [NOT] DISTINCT FROM NULL to be converted to IS [NOT] NULL for
proven null arguments (Richard Guo) §
The latter form is more easily optimized.
"""
Two optional ``[NOT]`` introduce ambiguity.

"""
Add support for INSERT ... RETURNING ... ON CONFLICT DO SELECT
(Andreas Karlsson, Marko Tiikkaja, Viktor Holmberg) §
This allows conflicting rows to be returns, and optionally locked with
FOR UPDATE/SHARE.
"""
I think it's:
INSERT... ON CONFLICT DO SELECT...RETURNING



--
jian
https://www.enterprisedb.com/





^ permalink  raw  reply  [nested|flat] 129+ messages in thread

* Re: First draft of PG 19 release notes
@ 2026-04-15 16:57  Bruce Momjian <bruce@momjian.us>
  parent: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>
  0 siblings, 2 replies; 129+ messages in thread

From: Bruce Momjian @ 2026-04-15 16:57 UTC (permalink / raw)
  To: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>; +Cc: Heikki Linnakangas <hlinnaka@iki.fi>; PostgreSQL-development <pgsql-hackers@lists.postgresql.org>

On Wed, Apr 15, 2026 at 07:55:56AM +0530, Ashutosh Bapat wrote:
> Hi Bruce,
> 
> On Wed, Apr 15, 2026 at 6:49 AM Bruce Momjian <bruce@momjian.us> wrote:
> >
> > I have completed the first draft of the PG 19 release notes:
> >
> >         https://www.postgresql.org/docs/devel/release-19.html
> >
> > The feature count is 212.  The recent average is 200:
> 
> One correction:
> 
> Add simplified shared memory registration function
> ShmemRequestStruct() (Ashutosh Bapat) §
> 
> Heikki Linnakangas is the primary author of this commit.
> 
> Also, depending upon the availability of space, here's a suggested version:
> 
> -- 
> Add simplified and improved shared memory registration function
> ShmemRequestStruct (Heikki Linnakangas, Ashutosh Bapat)

I have used your text above.  FYI, the commit message only has this for
author:

	Co-authored-by: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>

> Allows requesting named shared memory structures during and after
> server startup. Functions ShmemInitStruct() and ShmemInitHash() remain
> for backward compatibility.

I didn't add this text because the number of readers interested in this
change is very small.  Those who are interested can read the commit
message.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Do not let urgent matters crowd out time for investment in the future.





^ permalink  raw  reply  [nested|flat] 129+ messages in thread

* Re: First draft of PG 19 release notes
@ 2026-04-15 17:21  Jacob Champion <jacob.champion@enterprisedb.com>
  parent: Bruce Momjian <bruce@momjian.us>
  1 sibling, 1 reply; 129+ messages in thread

From: Jacob Champion @ 2026-04-15 17:21 UTC (permalink / raw)
  To: Bruce Momjian <bruce@momjian.us>; +Cc: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>; Heikki Linnakangas <hlinnaka@iki.fi>; PostgreSQL-development <pgsql-hackers@lists.postgresql.org>

On Wed, Apr 15, 2026 at 9:57 AM Bruce Momjian <bruce@momjian.us> wrote:
> I have used your text above.  FYI, the commit message only has this for
> author:
>
>         Co-authored-by: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>

The pattern of "a missing Author means the committer is the primary
author" was discussed at [1]; you asked if Co-authored-by was used
that way, and the answer was "yes". I use it, too.

Thanks,
--Jacob

[1] https://postgr.es/m/adO73c_EJKi05smk%40momjian.us





^ permalink  raw  reply  [nested|flat] 129+ messages in thread

* Re: First draft of PG 19 release notes
@ 2026-04-15 17:56  Melanie Plageman <melanieplageman@gmail.com>
  parent: Bruce Momjian <bruce@momjian.us>
  25 siblings, 1 reply; 129+ messages in thread

From: Melanie Plageman @ 2026-04-15 17:56 UTC (permalink / raw)
  To: Bruce Momjian <bruce@momjian.us>; +Cc: PostgreSQL-development <pgsql-hackers@lists.postgresql.org>

On Tue, Apr 14, 2026 at 9:19 PM Bruce Momjian <bruce@momjian.us> wrote:
>
> I have completed the first draft of the PG 19 release notes:
>
>         https://www.postgresql.org/docs/devel/release-19.html

As of b46e1e54d078def, SELECT queries may update the visibility map.
Previously only vacuum did this. I think users may be confused by this
if it is not mentioned in the release notes.

Additionally, users may notice that there are no longer
XLOG_HEAP2_VISIBLE records. A series of commits culminating in
a881cc9c7e819fb (others being d96f87332b378, add323da40a6bf9e0,
1252a4ee2863673, a759ced2f1e) moved VM setting into the
XLOG_HEAP2_PRUNE_VACUUM_SCAN record. Users may notice that
XLOG_HEAP2_VISIBLE records are no longer produced.

This is more minor, but we also now (378a216187aea1) set pd_prune_xid
on insert, so users may notice that a freshly inserted page is
on-access pruned and then the VM is set (which wouldn't have happened
before without vacuum).

- Melanie





^ permalink  raw  reply  [nested|flat] 129+ messages in thread

* Re: First draft of PG 19 release notes
@ 2026-04-15 18:41  Bruce Momjian <bruce@momjian.us>
  parent: David Rowley <dgrowleyml@gmail.com>
  0 siblings, 1 reply; 129+ messages in thread

From: Bruce Momjian @ 2026-04-15 18:41 UTC (permalink / raw)
  To: David Rowley <dgrowleyml@gmail.com>; +Cc: PostgreSQL-development <pgsql-hackers@lists.postgresql.org>

On Wed, Apr 15, 2026 at 02:29:49PM +1200, David Rowley wrote:
> On Wed, 15 Apr 2026 at 13:19, Bruce Momjian <bruce@momjian.us> wrote:
> > I have completed the first draft of the PG 19 release notes:
> >
> >         https://www.postgresql.org/docs/devel/release-19.html
> 
> Many thanks for your efforts here.
> 
> "Improve performance of internal row formation (David Rowley)"
> 
> It's really deformation, not formation. As far as I know, nothing in
> v19 sped up tuple formation.

Changed to:

	Improve performance of internal row deformation (David Rowley)
	                                    --
Thanks.

> I also think Nathan's work on autovacuum table prioritisation
> (d7965d65f) is worth a mention. There were concerns there that it
> might cause trouble for people who (for some reason) get best results
> from the previous pg_class-ordered priority. Having something in the
> notes about this might help direct someone towards why they're seeing
> autovacuum behave differently after upgrading.

Yikes, so I collected commits on March 26, but when I went to add new
commits, I used March 27 as the start date, and missed all the late
March 26 commits.  I should have started on March 26 to get
later-in-the-day commits!

I went back and looked at the commits I missed and the one you pointed
out is the only relevant one, so that is good.

Applied patch attached.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Do not let urgent matters crowd out time for investment in the future.





^ permalink  raw  reply  [nested|flat] 129+ messages in thread

* Re: First draft of PG 19 release notes
@ 2026-04-15 19:27  Bruce Momjian <bruce@momjian.us>
  parent: Jacob Champion <jacob.champion@enterprisedb.com>
  0 siblings, 1 reply; 129+ messages in thread

From: Bruce Momjian @ 2026-04-15 19:27 UTC (permalink / raw)
  To: Jacob Champion <jacob.champion@enterprisedb.com>; +Cc: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>; Heikki Linnakangas <hlinnaka@iki.fi>; PostgreSQL-development <pgsql-hackers@lists.postgresql.org>

On Wed, Apr 15, 2026 at 10:21:34AM -0700, Jacob Champion wrote:
> On Wed, Apr 15, 2026 at 9:57 AM Bruce Momjian <bruce@momjian.us> wrote:
> > I have used your text above.  FYI, the commit message only has this for
> > author:
> >
> >         Co-authored-by: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>
> 
> The pattern of "a missing Author means the committer is the primary
> author" was discussed at [1]; you asked if Co-authored-by was used
> that way, and the answer was "yes". I use it, too.

Well, I am guessing you didn't read this thread fully:

	https://www.postgresql.org/message-id/flat/adElLtegJxi6Yecv%40momjian.us

which opened with the question:

	In the PG 19 commits, I am seeing several commits with Author
	and Co-authored-by tags.  FYI, I think we agreed that only the
	Author names are mentioned as the authors in the release notes.

and I was told that authors and "Co-authored-by" should be listed;  they
are effectively the same, except that github recognizes
"Co-authored-by".

I _thought_ the plan from January 2025 until March 2026 was:

	https://wiki.postgresql.org/wiki/Commit_Message_Guidance
	Author:
	Co-authored-by:
	    Used to indicate the patch authors. "Co-authored-by:" is used by
	    committers when they want to give full credit to the named individuals,
	    but also indicate that they made significant changes.

This was specifically for "Co-authored-by:" == committer, but the text
was not clear enough.  However, that doesn't match your usage where a
missing "Author" is considered to be the committer.

At [1], https://postgr.es/m/adO73c_EJKi05smk, I said: 

	Wow, I never thought that was a valid pattern, but I see a few PG 19
	commit messages using that, e.g.:
	
	
		Author: Peter Eisentraut <peter(at)eisentraut(dot)org>
		2025-08-12 [5f19d13df] libpq: Set LDAP protocol version 3
		
		    libpq: Set LDAP protocol version 3
		
		    Some LDAP servers reject the default version 2 protocol.  So set
		    version 3 before starting the connection.  This matches how the
		    backend LDAP code has worked all along.
		
		    Co-authored-by: Andrew Jackson <andrewjackson947(at)gmail(dot)com>
		    Reviewed-by: Pavel Seleznev <pavel(dot)seleznev(at)gmail(dot)com>
		    Discussion: https://www.postgresql.org/message-id/flat/CAKK5BkHixcivSCA9pfd_eUp7wkLRhvQ6OtGLAYrWC%3Dk7E76LDQ%40m...
	
	
	Is that what people are using?  A missing Author, and co-authors means
	the committer is the author?  Right?  Shouldn't we document this?  That
	does give a unique use for Co-authored-by.

However, later emails said:

	https://www.postgresql.org/message-id/CA%2BTgmob_tz0%2BT1CcyTFwgQVThsoezY2fKib%3Dr%2BukAvVBXwM1gg%40...
	This whole discussion is crazy to me. Every Author and Co-Author
	should be listed in the release notes. If there is no author or
	co-author named in the commit message, then the committer should be
	listed as the sole author; otherwise, the exact list of authors and
	co-authors that the committer chose to include in the commit message
	should be credited.

and there are more emails saying that, so that is the rule I used, and
documented on the wiki is:

	https://wiki.postgresql.org/wiki/Commit_Message_Guidance
	Used to indicate the patch authors. If no "Author" or
	"Co-authored-by" is listed, the committer is assumed to be
	the author.

What I also said in the thread was:

	What I don't want to do is to re-litigate this again, and usually
	if we ignore what people said in the past, they will show up at
	some later time to try to undo what we are doing now.

I created the PG 19 release notes with Author == "Co-authored-by:", so
if committers have not done that for PG 19, I need them to either inform
me of the rules they used, supply a release note patch, or change the
release notes themselves.  And hopefully use agreed-upon rules in the
future, whatever we decide those are.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Do not let urgent matters crowd out time for investment in the future.





^ permalink  raw  reply  [nested|flat] 129+ messages in thread

* Re: First draft of PG 19 release notes
@ 2026-04-15 19:34  Bruce Momjian <bruce@momjian.us>
  parent: Bruce Momjian <bruce@momjian.us>
  0 siblings, 0 replies; 129+ messages in thread

From: Bruce Momjian @ 2026-04-15 19:34 UTC (permalink / raw)
  To: David Rowley <dgrowleyml@gmail.com>; +Cc: PostgreSQL-development <pgsql-hackers@lists.postgresql.org>

On Wed, Apr 15, 2026 at 02:41:22PM -0400, Bruce Momjian wrote:
> On Wed, Apr 15, 2026 at 02:29:49PM +1200, David Rowley wrote:
> > On Wed, 15 Apr 2026 at 13:19, Bruce Momjian <bruce@momjian.us> wrote:
> > > I have completed the first draft of the PG 19 release notes:
> > >
> > >         https://www.postgresql.org/docs/devel/release-19.html
> > 
> > Many thanks for your efforts here.
> > 
> > "Improve performance of internal row formation (David Rowley)"
> > 
> > It's really deformation, not formation. As far as I know, nothing in
> > v19 sped up tuple formation.
> 
> Changed to:
> 
> 	Improve performance of internal row deformation (David Rowley)
> 	                                    --
> Thanks.
> 
> > I also think Nathan's work on autovacuum table prioritisation
> > (d7965d65f) is worth a mention. There were concerns there that it
> > might cause trouble for people who (for some reason) get best results
> > from the previous pg_class-ordered priority. Having something in the
> > notes about this might help direct someone towards why they're seeing
> > autovacuum behave differently after upgrading.
> 
> Yikes, so I collected commits on March 26, but when I went to add new
> commits, I used March 27 as the start date, and missed all the late
> March 26 commits.  I should have started on March 26 to get
> later-in-the-day commits!
> 
> I went back and looked at the commits I missed and the one you pointed
> out is the only relevant one, so that is good.
> 
> Applied patch attached.

Oops, patch _now_ attached.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Do not let urgent matters crowd out time for investment in the future.
commit 23ec74c8a85
Author: Bruce Momjian <bruce@momjian.us>
Date:   Wed Apr 15 14:42:57 2026 -0400

    doc PG 19 relnotes:  add missing March 16 autovacuum score item
    
    Also fix "deformed" tuples.
    
    Reported-by: David Rowley
    
    Backpatch-through: CAApHDvrsyD3QKBO=dypNkyFzYOzQEbgy+xJLwn=y+h+bLSDd-g@mail.gmail.com

diff --git a/doc/src/sgml/release-19.sgml b/doc/src/sgml/release-19.sgml
index 28ca12da3c8..bae5008a4ab 100644
--- a/doc/src/sgml/release-19.sgml
+++ b/doc/src/sgml/release-19.sgml
@@ -733,7 +733,7 @@ Author: David Rowley <drowley@postgresql.org>
 
 <listitem>
 <para>
-Improve performance of internal row formation (David Rowley)
+Improve performance of internal row deformation (David Rowley)
 <ulink url="&commit_baseurl;c456e3911">&sect;</ulink>
 </para>
 </listitem>
@@ -1216,6 +1216,23 @@ Previously the checksum status could only be set at initialization and changed o
 </para>
 </listitem>
 
+<!--
+Author: Nathan Bossart <nathan@postgresql.org>
+2026-03-27 [d7965d65f] Add rudimentary table prioritization to autovacuum.
+-->
+
+<listitem>
+<para>
+Add scoring system to control the order that tables are autovacuumed (Nathan Bossart)
+<ulink url="&commit_baseurl;d7965d65f">&sect;</ulink>
+</para>
+
+<para>
+The new server variables are autovacuum_freeze_score_weight, autovacuum_multixact_freeze_score_weight, autovacuum_vacuum_score_weight, autovacuum_vacuum_insert_score_weight, and
+autovacuum_analyze_score_weight.
+</para>
+</listitem>
+
 <!--
 Author: Daniel Gustafsson <dgustafsson@postgresql.org>
 2026-03-18 [4f433025f] ssl: Serverside SNI support for libpq

Attachments:

  [text/plain] diff (1.6K, ../../ad_oOUQloVs-3k30@momjian.us/2-diff)
  download | inline diff:
commit 23ec74c8a85
Author: Bruce Momjian <bruce@momjian.us>
Date:   Wed Apr 15 14:42:57 2026 -0400

    doc PG 19 relnotes:  add missing March 16 autovacuum score item
    
    Also fix "deformed" tuples.
    
    Reported-by: David Rowley
    
    Backpatch-through: CAApHDvrsyD3QKBO=dypNkyFzYOzQEbgy+xJLwn=y+h+bLSDd-g@mail.gmail.com

diff --git a/doc/src/sgml/release-19.sgml b/doc/src/sgml/release-19.sgml
index 28ca12da3c8..bae5008a4ab 100644
--- a/doc/src/sgml/release-19.sgml
+++ b/doc/src/sgml/release-19.sgml
@@ -733,7 +733,7 @@ Author: David Rowley <drowley@postgresql.org>
 
 <listitem>
 <para>
-Improve performance of internal row formation (David Rowley)
+Improve performance of internal row deformation (David Rowley)
 <ulink url="&commit_baseurl;c456e3911">&sect;</ulink>
 </para>
 </listitem>
@@ -1216,6 +1216,23 @@ Previously the checksum status could only be set at initialization and changed o
 </para>
 </listitem>
 
+<!--
+Author: Nathan Bossart <nathan@postgresql.org>
+2026-03-27 [d7965d65f] Add rudimentary table prioritization to autovacuum.
+-->
+
+<listitem>
+<para>
+Add scoring system to control the order that tables are autovacuumed (Nathan Bossart)
+<ulink url="&commit_baseurl;d7965d65f">&sect;</ulink>
+</para>
+
+<para>
+The new server variables are autovacuum_freeze_score_weight, autovacuum_multixact_freeze_score_weight, autovacuum_vacuum_score_weight, autovacuum_vacuum_insert_score_weight, and
+autovacuum_analyze_score_weight.
+</para>
+</listitem>
+
 <!--
 Author: Daniel Gustafsson <dgustafsson@postgresql.org>
 2026-03-18 [4f433025f] ssl: Serverside SNI support for libpq

^ permalink  raw  reply  [nested|flat] 129+ messages in thread

* Re: First draft of PG 19 release notes
@ 2026-04-15 19:35  Bruce Momjian <bruce@momjian.us>
  parent: Peter Smith <smithpb2250@gmail.com>
  0 siblings, 0 replies; 129+ messages in thread

From: Bruce Momjian @ 2026-04-15 19:35 UTC (permalink / raw)
  To: Peter Smith <smithpb2250@gmail.com>; +Cc: PostgreSQL-development <pgsql-hackers@lists.postgresql.org>

On Wed, Apr 15, 2026 at 03:27:49PM +1000, Peter Smith wrote:
> Hi,
> 
> For this one:
> "Allow CREATE/ALTER PUBLICATION to exclude some tables using the
> EXCEPT TABLE clause (Vignesh C, Shlok Kyal)"
> 
> ~
> 
> The "EXCEPT TABLE" syntax was later changed to "EXCEPT (TABLE ...)",
> so where above says "EXCEPT TABLE clause", probably now that should
> just say "EXCEPT clause" same as the documentation.

Yep, attached patch applied.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Do not let urgent matters crowd out time for investment in the future.

Attachments:

  [text/x-diff] master.diff (646B, ../../ad_olS90Tgr79xB0@momjian.us/2-master.diff)
  download | inline diff:
diff --git a/doc/src/sgml/release-19.sgml b/doc/src/sgml/release-19.sgml
index bae5008a4ab..3477c338f57 100644
--- a/doc/src/sgml/release-19.sgml
+++ b/doc/src/sgml/release-19.sgml
@@ -1462,7 +1462,7 @@ Author: Amit Kapila <akapila@postgresql.org>
 
 <listitem>
 <para>
-Allow CREATE/ALTER PUBLICATION to exclude some tables using the EXCEPT TABLE clause (Vignesh C, Shlok Kyal)
+Allow CREATE/ALTER PUBLICATION to exclude some tables using the EXCEPT clause (Vignesh C, Shlok Kyal)
 <ulink url="&commit_baseurl;493f8c643">&sect;</ulink>
 <ulink url="&commit_baseurl;6b0550c45">&sect;</ulink>
 <ulink url="&commit_baseurl;fd366065e">&sect;</ulink>

^ permalink  raw  reply  [nested|flat] 129+ messages in thread

* Re: First draft of PG 19 release notes
@ 2026-04-15 19:38  Bruce Momjian <bruce@momjian.us>
  parent: Laurenz Albe <laurenz.albe@cybertec.at>
  0 siblings, 0 replies; 129+ messages in thread

From: Bruce Momjian @ 2026-04-15 19:38 UTC (permalink / raw)
  To: Laurenz Albe <laurenz.albe@cybertec.at>; +Cc: PostgreSQL-development <pgsql-hackers@lists.postgresql.org>

On Wed, Apr 15, 2026 at 10:57:25AM +0200, Laurenz Albe wrote:
> On Tue, 2026-04-14 at 21:18 -0400, Bruce Momjian wrote:
> > I have completed the first draft of the PG 19 release notes:
> > 
> > 	https://www.postgresql.org/docs/devel/release-19.html
> 
> Thank you!
> 
> I noticed a typo:
> 
>   Change vacuumdb's --analyze-only option to analyze partitioned tables when now targets are specified
> 
> It should probably be "no targets" rather than "now targets".

"Now targets" did have a sense of immediacy, but unfortunately
inaccurate.  ;-)   Fixed.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Do not let urgent matters crowd out time for investment in the future.

Attachments:

  [text/x-diff] master.diff (598B, ../../ad_pGq7QUzjCLaeQ@momjian.us/2-master.diff)
  download | inline diff:
diff --git a/doc/src/sgml/release-19.sgml b/doc/src/sgml/release-19.sgml
index 3477c338f57..feaec880171 100644
--- a/doc/src/sgml/release-19.sgml
+++ b/doc/src/sgml/release-19.sgml
@@ -2562,7 +2562,7 @@ Author: Fujii Masao <fujii@postgresql.org>
 
 <listitem>
 <para>
-Change vacuumdb's --analyze-only option to analyze partitioned tables when now targets are specified (Laurenz Albe, Mircea Cadariu)
+Change vacuumdb's --analyze-only option to analyze partitioned tables when no targets are specified (Laurenz Albe, Mircea Cadariu)
 <ulink url="&commit_baseurl;6429e5b77">&sect;</ulink>
 </para>
 

^ permalink  raw  reply  [nested|flat] 129+ messages in thread

* Re: First draft of PG 19 release notes
@ 2026-04-15 19:46  Bruce Momjian <bruce@momjian.us>
  parent: Daniel Gustafsson <daniel@yesql.se>
  0 siblings, 0 replies; 129+ messages in thread

From: Bruce Momjian @ 2026-04-15 19:46 UTC (permalink / raw)
  To: Daniel Gustafsson <daniel@yesql.se>; +Cc: PostgreSQL-development <pgsql-hackers@lists.postgresql.org>

On Wed, Apr 15, 2026 at 01:18:50PM +0200, Daniel Gustafsson wrote:
> > On 15 Apr 2026, at 03:18, Bruce Momjian <bruce@momjian.us> wrote:
> > 
> > I have completed the first draft of the PG 19 release notes:
> 
> +Allow online enabling and disabling of data checksums (Daniel Gustafsson, Magnus Hagander, Tomas Vondra, Lakshmi N)
> 
> This one should only say "Daniel Gustafsson, Magnus Hagander, Tomas Vondra"

Okay, I added "Lakshmi N" because of this commit which is linked to from
the release notes:

	commit b364828f825
	Author: Daniel Gustafsson <dgustafsson@postgresql.org>
	Date:   Wed Apr 8 22:53:43 2026 +0300
	
	    doc: Fix data_checksums data type
	
	    Commit f19c0eccae96 changed the data_checksums GUC datatype from a
	    boolean to an enum.  This updates the documentation to accurately
	    reflect its new type and document the new possible states: 'on',
	    'off', 'inprogress-on', and 'inprogress-off'.
	
	    Also update the xref for more information to point to the section
	    on data checksums rather than the initdb checksum option.
	
	    Author: Lakshmi N <lakshmin.jhs@gmail.com>
	    Reviewed-by: Daniel Gustafsson <daniel@yesql.se>
	    Discussion:	https://postgr.es/m/CA+3i_M-AtTnqTB2KLBTpu-c-jvnTuy7bGxyxs80rgiQLxWrRUQ@mail.gmail.com

but it is only a small doc patch, so makes sense to remove him.  I
debated this one at the time I added his name.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Do not let urgent matters crowd out time for investment in the future.





^ permalink  raw  reply  [nested|flat] 129+ messages in thread

* Re: First draft of PG 19 release notes
@ 2026-04-15 20:18  Bruce Momjian <bruce@momjian.us>
  parent: jian he <jian.universality@gmail.com>
  0 siblings, 0 replies; 129+ messages in thread

From: Bruce Momjian @ 2026-04-15 20:18 UTC (permalink / raw)
  To: jian he <jian.universality@gmail.com>; +Cc: PostgreSQL-development <pgsql-hackers@lists.postgresql.org>

On Wed, Apr 15, 2026 at 10:59:13PM +0800, jian he wrote:
> On Wed, Apr 15, 2026 at 9:19 AM Bruce Momjian <bruce@momjian.us> wrote:
> >
> > I have completed the first draft of the PG 19 release notes:
> >
> >         https://www.postgresql.org/docs/devel/release-19.html
> >
> 
> https://git.postgresql.org/cgit/postgresql.git/commit/?id=ecd9288624a1582a732cf86ac5a01475a1ce7815

I don't usually mention test changes in the release notes.

> https://git.postgresql.org/cgit/postgresql.git/commit/?id=4edd6036d69ce42ac1af236f659f20daed65c8d4

Uh, the commit message is:

	commit 4edd6036d69
	Author: Tom Lane <tgl@sss.pgh.pa.us>
	Date:   Tue Apr 7 14:45:33 2026 -0400
	
	    Fix WITHOUT OVERLAPS' interaction with domains.
	
	    UNIQUE/PRIMARY KEY ... WITHOUT OVERLAPS requires the no-overlap
	    column to be a range or multirange, but it should allow a domain
	    over such a type too.  This requires minor adjustments in both
	    the parser and executor.
	
	    In passing, fix a nearby break-instead-of-continue thinko in
	    transformIndexConstraint.  This had the effect of disabling
	    parse-time validation of the no-overlap column's type in the context
	    of ALTER TABLE ADD CONSTRAINT, if it follows a dropped column.
	    We'd still complain appropriately at runtime though.
	
	    Author: Jian He <jian.universality@gmail.com>
	    Reviewed-by: Paul A Jungwirth <pj@illuminatedcomputing.com>
	    Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>
	    Discussion:	https://postgr.es/m/CACJufxGoAmN_0iJ=hjTG0vGpOSOyy-vYyfE+-q0AWxrq2_p5XQ@mail.gmail.com
-->	    Backpatch-through: 18

Since it is backpatched to PG 18, it shouldn't appear in the PG 19
release notes.

> """
> Allow COPY TO to output partitioned tables (Jian He, Ajin Cherian) § §
> Previously COPY (SELECT ...) has to be used to output partitioned tables.
> """
> The second commit uses this feature, so i guess the commit message
> needs a slight change.

Updated in attached patch.

> """
> Improve timing performance measurements (Lukas Fittl, Andres Freund,
> David Geier, Lukas Fittl, David Geier) § §
> This benefits EXPLAIN (ANALYZE, TIMING) and pg_test_timing, and is
> controlled via server variable timing_clock_source.
> """
> Duplicated name entry.

Fixed in attached patch.

> """
> Allow IS [NOT] DISTINCT FROM NULL to be converted to IS [NOT] NULL for
> proven null arguments (Richard Guo) §
> The latter form is more easily optimized.
> """
> Two optional ``[NOT]`` introduce ambiguity.

Uh, if the NOT is in the first, it is in the second.  Is that confusing?
Suggestions?

> """
> Add support for INSERT ... RETURNING ... ON CONFLICT DO SELECT
> (Andreas Karlsson, Marko Tiikkaja, Viktor Holmberg) §
> This allows conflicting rows to be returns, and optionally locked with
> FOR UPDATE/SHARE.
> """
> I think it's:
> INSERT... ON CONFLICT DO SELECT...RETURNING

Uh, went by the commit messsage which says:

	The INSERT statement must have a RETURNING clause, when DO SELECT
	is specified.

However, all the examples have the syntax as you specified, so I must
have interpreted it wrong.

Applied patch attached.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Do not let urgent matters crowd out time for investment in the future.

Attachments:

  [text/x-diff] master.diff (1.3K, ../../ad_yfCmLaV3bwg3B@momjian.us/2-master.diff)
  download | inline diff:
diff --git a/doc/src/sgml/release-19.sgml b/doc/src/sgml/release-19.sgml
index 1ae86ad0036..2137621f6a6 100644
--- a/doc/src/sgml/release-19.sgml
+++ b/doc/src/sgml/release-19.sgml
@@ -771,7 +771,7 @@ Author: Andres Freund <andres@anarazel.de>
 
 <listitem>
 <para>
-Improve timing performance measurements (Lukas Fittl, Andres Freund, David Geier, Lukas Fittl, David Geier)
+Improve timing performance measurements (Lukas Fittl, Andres Freund, David Geier, Lukas Fittl)
 <ulink url="&commit_baseurl;294520c44">&sect;</ulink>
 <ulink url="&commit_baseurl;16fca4825">&sect;</ulink>
 </para>
@@ -1717,7 +1717,7 @@ Author: Dean Rasheed <dean.a.rasheed@gmail.com>
 
 <listitem>
 <para>
-Add support for INSERT ... RETURNING ... ON CONFLICT DO SELECT (Andreas Karlsson,  Marko Tiikkaja, Viktor Holmberg)
+Add support for INSERT ... ON CONFLICT DO SELECT ... RETURNING (Andreas Karlsson,  Marko Tiikkaja, Viktor Holmberg)
 <ulink url="&commit_baseurl;88327092f">&sect;</ulink>
 </para>
 
@@ -1999,7 +1999,7 @@ Allow COPY TO to output partitioned tables (Jian He, Ajin Cherian)
 </para>
 
 <para>
-Previously COPY (SELECT ...) has to be used to output partitioned tables.
+Previously COPY (SELECT ...) had to be used to output partitioned tables.  This also improves logical replication table synchronization.
 </para>
 </listitem>
 

^ permalink  raw  reply  [nested|flat] 129+ messages in thread

* Re: First draft of PG 19 release notes
@ 2026-04-15 20:51  Bruce Momjian <bruce@momjian.us>
  parent: Melanie Plageman <melanieplageman@gmail.com>
  0 siblings, 0 replies; 129+ messages in thread

From: Bruce Momjian @ 2026-04-15 20:51 UTC (permalink / raw)
  To: Melanie Plageman <melanieplageman@gmail.com>; +Cc: PostgreSQL-development <pgsql-hackers@lists.postgresql.org>

On Wed, Apr 15, 2026 at 01:56:50PM -0400, Melanie Plageman wrote:
> On Tue, Apr 14, 2026 at 9:19 PM Bruce Momjian <bruce@momjian.us> wrote:
> >
> > I have completed the first draft of the PG 19 release notes:
> >
> >         https://www.postgresql.org/docs/devel/release-19.html
> 
> As of b46e1e54d078def, SELECT queries may update the visibility map.
> Previously only vacuum did this. I think users may be confused by this
> if it is not mentioned in the release notes.

Yes, I puzzled on this one and I am glad you clarified its purpose.
I think it should be added, and I have applied the attached patch.

> Additionally, users may notice that there are no longer
> XLOG_HEAP2_VISIBLE records. A series of commits culminating in
> a881cc9c7e819fb (others being d96f87332b378, add323da40a6bf9e0,
> 1252a4ee2863673, a759ced2f1e) moved VM setting into the
> XLOG_HEAP2_PRUNE_VACUUM_SCAN record. Users may notice that
> XLOG_HEAP2_VISIBLE records are no longer produced.
> 
> This is more minor, but we also now (378a216187aea1) set pd_prune_xid
> on insert, so users may notice that a freshly inserted page is
> on-access pruned and then the VM is set (which wouldn't have happened
> before without vacuum).

Uh, I don't want to get into the internals too much in the release
notes, in fear of confusing/losing readers.  I think this is too
low-level to mention, but we now have a good "prune" item so if they see
big improvements, they will know why.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Do not let urgent matters crowd out time for investment in the future.

Attachments:

  [text/x-diff] master.diff (840B, ../../ad_6RBwUlRooQK-9@momjian.us/2-master.diff)
  download | inline diff:
diff --git a/doc/src/sgml/release-19.sgml b/doc/src/sgml/release-19.sgml
index 2137621f6a6..6e038851a67 100644
--- a/doc/src/sgml/release-19.sgml
+++ b/doc/src/sgml/release-19.sgml
@@ -596,6 +596,22 @@ New server variables are io_min_workers, io_max_workers, io_worker_idle_timeout,
 </para>
 </listitem>
 
+<!--
+Author: Melanie Plageman <melanieplageman@gmail.com>
+2026-03-30 [b46e1e54d] Allow on-access pruning to set pages all-visible
+-->
+
+<listitem>
+<para>
+Allow query table scans to mark pages as all-visible in the free space map (Melanie Plageman)
+<ulink url="&commit_baseurl;b46e1e54d">&sect;</ulink>
+</para>
+
+<para>
+Previously only VACUUM and COPY FREEZE could this.
+</para>
+</listitem>
+
 <!--
 Author: Masahiko Sawada <msawada@postgresql.org>
 2026-04-06 [1ff3180ca] Allow autovacuum to use parallel vacuum workers.

^ permalink  raw  reply  [nested|flat] 129+ messages in thread

* Re: First draft of PG 19 release notes
@ 2026-04-16 02:22  Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>
  parent: Bruce Momjian <bruce@momjian.us>
  1 sibling, 0 replies; 129+ messages in thread

From: Ashutosh Bapat @ 2026-04-16 02:22 UTC (permalink / raw)
  To: Bruce Momjian <bruce@momjian.us>; +Cc: Heikki Linnakangas <hlinnaka@iki.fi>; PostgreSQL-development <pgsql-hackers@lists.postgresql.org>

On Wed, Apr 15, 2026 at 10:27 PM Bruce Momjian <bruce@momjian.us> wrote:
>
> On Wed, Apr 15, 2026 at 07:55:56AM +0530, Ashutosh Bapat wrote:
> > Hi Bruce,
> >
> > On Wed, Apr 15, 2026 at 6:49 AM Bruce Momjian <bruce@momjian.us> wrote:
> > >
> > > I have completed the first draft of the PG 19 release notes:
> > >
> > >         https://www.postgresql.org/docs/devel/release-19.html
> > >
> > > The feature count is 212.  The recent average is 200:
> >
> > One correction:
> >
> > Add simplified shared memory registration function
> > ShmemRequestStruct() (Ashutosh Bapat) §
> >
> > Heikki Linnakangas is the primary author of this commit.
> >
> > Also, depending upon the availability of space, here's a suggested version:
> >
> > --
> > Add simplified and improved shared memory registration function
> > ShmemRequestStruct (Heikki Linnakangas, Ashutosh Bapat)
>
> I have used your text above.  FYI, the commit message only has this for
> author:
>
>         Co-authored-by: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>

Thanks for accepting the suggestion.

>
> > Allows requesting named shared memory structures during and after
> > server startup. Functions ShmemInitStruct() and ShmemInitHash() remain
> > for backward compatibility.
>
> I didn't add this text because the number of readers interested in this
> change is very small.  Those who are interested can read the commit
> message.

Fair enough.

-- 
Best Wishes,
Ashutosh Bapat





^ permalink  raw  reply  [nested|flat] 129+ messages in thread

* Re: First draft of PG 19 release notes
@ 2026-04-16 05:47  Masahiko Sawada <sawada.mshk@gmail.com>
  parent: Bruce Momjian <bruce@momjian.us>
  25 siblings, 1 reply; 129+ messages in thread

From: Masahiko Sawada @ 2026-04-16 05:47 UTC (permalink / raw)
  To: Bruce Momjian <bruce@momjian.us>; +Cc: PostgreSQL-development <pgsql-hackers@lists.postgresql.org>

On Tue, Apr 14, 2026 at 6:19 PM Bruce Momjian <bruce@momjian.us> wrote:
>
> I have completed the first draft of the PG 19 release notes:
>
>         https://www.postgresql.org/docs/devel/release-19.html

Thank you for working on this.

"Add memory usage and parallelism reporting to VACUUM (VERBOSE) and
autovacuum logs (Masahiko Sawada, Daniil Davydov)"

Please revise the author of the memory usage report to vacuum logs to
Tatsuya Kawata. I missed credit him as the author in the original
commit[1].

I've attached the patch.

Regards,

[1] https://www.postgresql.org/message-id/CAD21AoD8NOPCZ6_b0Kt1rdaMtwSU2PaAhwcecEBj4ifEySvLRw%40mail.gma...

-- 
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com

Attachments:

  [text/x-patch] v1-0001-doc-PG19-relnotes-fix-author-of-memory-usage-repo.patch (975B, ../../CAD21AoCLCZnzEFam8H07qq-=fUpDwmTmV7+4RPnT2x_xoJBrgg@mail.gmail.com/2-v1-0001-doc-PG19-relnotes-fix-author-of-memory-usage-repo.patch)
  download | inline diff:
From f8f67c5f10abe6e46a8efbb79b28cb5fc602a455 Mon Sep 17 00:00:00 2001
From: Masahiko Sawada <sawada.mshk@gmail.com>
Date: Wed, 15 Apr 2026 22:42:29 -0700
Subject: [PATCH v1] doc PG19 relnotes: fix author of memory usage report in
 vacuum logs.

---
 doc/src/sgml/release-19.sgml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/doc/src/sgml/release-19.sgml b/doc/src/sgml/release-19.sgml
index 76bbfc0891d..bd03f8d54f6 100644
--- a/doc/src/sgml/release-19.sgml
+++ b/doc/src/sgml/release-19.sgml
@@ -1877,7 +1877,7 @@ Author: Masahiko Sawada <msawada@postgresql.org>
 
 <listitem>
 <para>
-Add memory usage and parallelism reporting to VACUUM (VERBOSE) and autovacuum logs (Masahiko Sawada, Daniil Davydov)
+Add memory usage and parallelism reporting to VACUUM (VERBOSE) and autovacuum logs (Tatsuya Kawata, Daniil Davydov)
 <ulink url="&commit_baseurl;736f754ee">&sect;</ulink>
 <ulink url="&commit_baseurl;adcdbe938">&sect;</ulink>
 </para>
-- 
2.53.0



^ permalink  raw  reply  [nested|flat] 129+ messages in thread

* Re: First draft of PG 19 release notes
@ 2026-04-16 06:38  David Geier <geidav.pg@gmail.com>
  parent: Bruce Momjian <bruce@momjian.us>
  25 siblings, 1 reply; 129+ messages in thread

From: David Geier @ 2026-04-16 06:38 UTC (permalink / raw)
  To: Bruce Momjian <bruce@momjian.us>; PostgreSQL-development <pgsql-hackers@lists.postgresql.org>

Hi Bruce!

On 15.04.2026 03:18, Bruce Momjian wrote:
> I have completed the first draft of the PG 19 release notes:
> 
> 	https://www.postgresql.org/docs/devel/release-19.html
> 
> The feature count is 212.  The recent average is 200:
> 
> 	https://momjian.us/main/writings/pgsql/missing.pdf#page=3
> 

How about also including the improvements we did for reducing GIN index
build times, see [1]? Not all patches have been committed yet but the
ones that got committed already make a meaningful difference.

[1]
https://www.postgresql.org/message-id/flat/5d366878-2007-4d31-861e-19294b7a583b%40gmail.com

--
David Geier





^ permalink  raw  reply  [nested|flat] 129+ messages in thread

* Re: First draft of PG 19 release notes
@ 2026-04-16 07:49  Richard Guo <guofenglinux@gmail.com>
  parent: Bruce Momjian <bruce@momjian.us>
  25 siblings, 1 reply; 129+ messages in thread

From: Richard Guo @ 2026-04-16 07:49 UTC (permalink / raw)
  To: Bruce Momjian <bruce@momjian.us>; +Cc: PostgreSQL-development <pgsql-hackers@lists.postgresql.org>

On Wed, Apr 15, 2026 at 10:19 AM Bruce Momjian <bruce@momjian.us> wrote:
> I have completed the first draft of the PG 19 release notes:
>
>         https://www.postgresql.org/docs/devel/release-19.html

Thanks for putting in all this work!

The co-author is missing from this item:
* Allow more LEFT JOINs to be converted to ANTI JOINs (Tender Wang)

Three items authored by me are under General Performance but should be
under Optimizer, as they are planner-time expression transformations.
I also fixed some wording issues in those items and one other
Optimizer item.

Attached is the patch.

- Richard

Attachments:

  [application/octet-stream] v1-0001-Fix-draft-of-PG-19-release-notes.patch (3.9K, ../../CAMbWs4_etzZZPMEzte8hJv2f4Tn6dGskg8v1R_N9uCd2of0kMQ@mail.gmail.com/2-v1-0001-Fix-draft-of-PG-19-release-notes.patch)
  download | inline diff:
From a9076dec5e96d073df8825557ac53afa486e34af Mon Sep 17 00:00:00 2001
From: Richard Guo <guofenglinux@gmail.com>
Date: Thu, 16 Apr 2026 15:56:32 +0900
Subject: [PATCH v1] Fix draft of PG 19 release notes

---
 doc/src/sgml/release-19.sgml | 82 ++++++++++++++++++------------------
 1 file changed, 41 insertions(+), 41 deletions(-)

diff --git a/doc/src/sgml/release-19.sgml b/doc/src/sgml/release-19.sgml
index 76bbfc0891d..0016e8ec775 100644
--- a/doc/src/sgml/release-19.sgml
+++ b/doc/src/sgml/release-19.sgml
@@ -329,7 +329,7 @@ Author: Richard Guo <rguo@postgresql.org>
 
 <listitem>
 <para>
-Allow more LEFT JOINs to be converted to ANTI JOINs (Tender Wang)
+Allow more LEFT JOINs to be converted to ANTI JOINs (Tender Wang, Richard Guo)
 <ulink url="&commit_baseurl;cf74558fe">&sect;</ulink>
 </para>
 </listitem>
@@ -377,7 +377,7 @@ Author: Richard Guo <rguo@postgresql.org>
 
 <listitem>
 <para>
-Allow IS [NOT] DISTINCT FROM NULL to be converted to IS [NOT] NULL for proven null arguments (Richard Guo)
+Convert IS [NOT] DISTINCT FROM NULL to IS [NOT] NULL during constant folding (Richard Guo)
 <ulink url="&commit_baseurl;f41ab5157">&sect;</ulink>
 </para>
 
@@ -452,6 +452,45 @@ This information is used by the optimizer in planning memory usage.
 </para>
 </listitem>
 
+<!--
+Author: Richard Guo <rguo@postgresql.org>
+2026-02-10 [0aaf0de7f] Optimize BooleanTest with non-nullable input
+-->
+
+<listitem>
+<para>
+Simplify IS [NOT] TRUE/FALSE/UNKNOWN to plain boolean expressions when the input is proven non-nullable (Richard Guo)
+<ulink url="&commit_baseurl;0aaf0de7f">&sect;</ulink>
+</para>
+</listitem>
+
+<!--
+Author: Richard Guo <rguo@postgresql.org>
+2025-12-24 [10c4fe074] Simplify COALESCE expressions using non-nullable argumen
+Author: Richard Guo <rguo@postgresql.org>
+2025-12-24 [cb7b7ec7a] Optimize ROW(...) IS [NOT] NULL using non-nullable field
+-->
+
+<listitem>
+<para>
+Simplify COALESCE and ROW(...) IS [NOT] NULL to avoid evaluating unnecessary arguments (Richard Guo)
+<ulink url="&commit_baseurl;10c4fe074">&sect;</ulink>
+<ulink url="&commit_baseurl;cb7b7ec7a">&sect;</ulink>
+</para>
+</listitem>
+
+<!--
+Author: Richard Guo <rguo@postgresql.org>
+2026-02-10 [0a3796125] Optimize IS DISTINCT FROM with non-nullable inputs
+-->
+
+<listitem>
+<para>
+Simplify IS [NOT] DISTINCT FROM to equality/inequality operators when inputs are proven non-nullable (Richard Guo)
+<ulink url="&commit_baseurl;0a3796125">&sect;</ulink>
+</para>
+</listitem>
+
 <!--
 Author: Tom Lane <tgl@sss.pgh.pa.us>
 2025-11-19 [057012b20] Speed up eqjoinsel() with lots of MCV entries.
@@ -687,45 +726,6 @@ Previously this always required a table rewrite.
 </para>
 </listitem>
 
-<!--
-Author: Richard Guo <rguo@postgresql.org>
-2026-02-10 [0aaf0de7f] Optimize BooleanTest with non-nullable input
--->
-
-<listitem>
-<para>
-Allow IS [NOT] TRUE/FALSE/UNKNOWN to be evaluated earlier for proven non-null arguments (Richard Guo)
-<ulink url="&commit_baseurl;0aaf0de7f">&sect;</ulink>
-</para>
-</listitem>
-
-<!--
-Author: Richard Guo <rguo@postgresql.org>
-2025-12-24 [10c4fe074] Simplify COALESCE expressions using non-nullable argumen
-Author: Richard Guo <rguo@postgresql.org>
-2025-12-24 [cb7b7ec7a] Optimize ROW(...) IS [NOT] NULL using non-nullable field
--->
-
-<listitem>
-<para>
-Simplify COALESCE and ROW(...) IS [NOT] NULL to avoid evaluating unnecessary arguments (Richard Guo)
-<ulink url="&commit_baseurl;10c4fe074">&sect;</ulink>
-<ulink url="&commit_baseurl;cb7b7ec7a">&sect;</ulink>
-</para>
-</listitem>
-
-<!--
-Author: Richard Guo <rguo@postgresql.org>
-2026-02-10 [0a3796125] Optimize IS DISTINCT FROM with non-nullable inputs
--->
-
-<listitem>
-<para>
-Allow IS DISTINCT FROM to be evaluated earlier for non-constant arguments (Richard Guo)
-<ulink url="&commit_baseurl;0a3796125">&sect;</ulink>
-</para>
-</listitem>
-
 <!--
 Author: Michael Paquier <michael@paquier.xyz>
 2026-03-05 [34dfca293] Change default value of default_toast_compression to "lz
-- 
2.39.5 (Apple Git-154)



^ permalink  raw  reply  [nested|flat] 129+ messages in thread

* Re: First draft of PG 19 release notes
@ 2026-04-16 07:54  Michael Banck <mbanck@gmx.net>
  parent: Bruce Momjian <bruce@momjian.us>
  0 siblings, 1 reply; 129+ messages in thread

From: Michael Banck @ 2026-04-16 07:54 UTC (permalink / raw)
  To: Bruce Momjian <bruce@momjian.us>; +Cc: Jacob Champion <jacob.champion@enterprisedb.com>; Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>; Heikki Linnakangas <hlinnaka@iki.fi>; PostgreSQL-development <pgsql-hackers@lists.postgresql.org>

Hi,

On Wed, Apr 15, 2026 at 03:27:06PM -0400, Bruce Momjian wrote:
> On Wed, Apr 15, 2026 at 10:21:34AM -0700, Jacob Champion wrote:
> > On Wed, Apr 15, 2026 at 9:57 AM Bruce Momjian <bruce@momjian.us> wrote:
> > > I have used your text above.  FYI, the commit message only has this for
> > > author:
> > >
> > >         Co-authored-by: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>
> > 
> > The pattern of "a missing Author means the committer is the primary
> > author" was discussed at [1]; you asked if Co-authored-by was used
> > that way, and the answer was "yes". I use it, too.
> 
> Well, I am guessing you didn't read this thread fully:
> 
> 	https://www.postgresql.org/message-id/flat/adElLtegJxi6Yecv%40momjian.us
> 
> which opened with the question:
> 
> 	In the PG 19 commits, I am seeing several commits with Author
> 	and Co-authored-by tags.  FYI, I think we agreed that only the
> 	Author names are mentioned as the authors in the release notes.
> 
> and I was told that authors and "Co-authored-by" should be listed;  they
> are effectively the same, except that github recognizes
> "Co-authored-by".
> 
> I _thought_ the plan from January 2025 until March 2026 was:
> 
> 	https://wiki.postgresql.org/wiki/Commit_Message_Guidance
> 	Author:
> 	Co-authored-by:
> 	    Used to indicate the patch authors. "Co-authored-by:" is used by
> 	    committers when they want to give full credit to the named individuals,
> 	    but also indicate that they made significant changes.
> 
> This was specifically for "Co-authored-by:" == committer, but the text
> was not clear enough.  However, that doesn't match your usage where a
> missing "Author" is considered to be the committer.

I think if the committer omits an "Author" tag, but credits a
non-committer as "Co-Author", then both the committer and the
non-committer should be considered authors and credited in the release
notes.

What would be the use-case for a sole non-committer "Co-Author" (as
opposed to just crediting the non-committer as "Author") otherwise be?


Michael





^ permalink  raw  reply  [nested|flat] 129+ messages in thread

* Re: First draft of PG 19 release notes
@ 2026-04-16 15:13  Bruce Momjian <bruce@momjian.us>
  parent: Michael Banck <mbanck@gmx.net>
  0 siblings, 0 replies; 129+ messages in thread

From: Bruce Momjian @ 2026-04-16 15:13 UTC (permalink / raw)
  To: Michael Banck <mbanck@gmx.net>; +Cc: Jacob Champion <jacob.champion@enterprisedb.com>; Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>; Heikki Linnakangas <hlinnaka@iki.fi>; PostgreSQL-development <pgsql-hackers@lists.postgresql.org>

On Thu, Apr 16, 2026 at 09:54:57AM +0200, Michael Banck wrote:
> > Well, I am guessing you didn't read this thread fully:
> > 
> > 	https://www.postgresql.org/message-id/flat/adElLtegJxi6Yecv%40momjian.us
> >
> > This was specifically for "Co-authored-by:" == committer, but the text
> > was not clear enough.  However, that doesn't match your usage where a
> > missing "Author" is considered to be the committer.
> 
> I think if the committer omits an "Author" tag, but credits a
> non-committer as "Co-Author", then both the committer and the
> non-committer should be considered authors and credited in the release
> notes.
> 
> What would be the use-case for a sole non-committer "Co-Author" (as
> opposed to just crediting the non-committer as "Author") otherwise be?

I agree with you, and made that case in January of 2025 and in the email
thread URL above.  However, I seemed to annoy people more than help
them, so I am not going to revisit it.  If someone else wants to restart
that thread and get a different consensus, feel free to do so.

My guess is that most (vocal?) committers prefer to have Author and
Co-Author indicate different levels of authorship in the commit text,
rather than have them have different behavior for release note
authorship.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Do not let urgent matters crowd out time for investment in the future.





^ permalink  raw  reply  [nested|flat] 129+ messages in thread

* Re: First draft of PG 19 release notes
@ 2026-04-16 15:24  Bruce Momjian <bruce@momjian.us>
  parent: Masahiko Sawada <sawada.mshk@gmail.com>
  0 siblings, 0 replies; 129+ messages in thread

From: Bruce Momjian @ 2026-04-16 15:24 UTC (permalink / raw)
  To: Masahiko Sawada <sawada.mshk@gmail.com>; +Cc: PostgreSQL-development <pgsql-hackers@lists.postgresql.org>

On Wed, Apr 15, 2026 at 10:47:58PM -0700, Masahiko Sawada wrote:
> On Tue, Apr 14, 2026 at 6:19 PM Bruce Momjian <bruce@momjian.us> wrote:
> >
> > I have completed the first draft of the PG 19 release notes:
> >
> >         https://www.postgresql.org/docs/devel/release-19.html
> 
> Thank you for working on this.
> 
> "Add memory usage and parallelism reporting to VACUUM (VERBOSE) and
> autovacuum logs (Masahiko Sawada, Daniil Davydov)"
> 
> Please revise the author of the memory usage report to vacuum logs to
> Tatsuya Kawata. I missed credit him as the author in the original
> commit[1].
> 
> I've attached the patch.

Great, patch applied.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Do not let urgent matters crowd out time for investment in the future.





^ permalink  raw  reply  [nested|flat] 129+ messages in thread

* Re: First draft of PG 19 release notes
@ 2026-04-16 16:14  Bruce Momjian <bruce@momjian.us>
  parent: David Geier <geidav.pg@gmail.com>
  0 siblings, 1 reply; 129+ messages in thread

From: Bruce Momjian @ 2026-04-16 16:14 UTC (permalink / raw)
  To: David Geier <geidav.pg@gmail.com>; +Cc: PostgreSQL-development <pgsql-hackers@lists.postgresql.org>

On Thu, Apr 16, 2026 at 08:38:45AM +0200, David Geier wrote:
> Hi Bruce!
> 
> On 15.04.2026 03:18, Bruce Momjian wrote:
> > I have completed the first draft of the PG 19 release notes:
> > 
> > 	https://www.postgresql.org/docs/devel/release-19.html
> > 
> > The feature count is 212.  The recent average is 200:
> > 
> > 	https://momjian.us/main/writings/pgsql/missing.pdf#page=3
> > 
> 
> How about also including the improvements we did for reducing GIN index
> build times, see [1]? Not all patches have been committed yet but the
> ones that got committed already make a meaningful difference.
> 
> [1]
> https://www.postgresql.org/message-id/flat/5d366878-2007-4d31-861e-19294b7a583b%40gmail.com

This is an interesting case.  First, I looked at the commit logs and
didn't see anything talking about improving the speed of GIN index
builds.  So then I looked at the first email in the thread and saw 3x
improvement for pg_trgm, so I looked in the commit logs for pg_trgm and
didn't see any speedup mentioned.

I then looked at the posted patches and this might be a case where there
are a number of targeted improvements that didn't specify the larger
goal, so there is no goal mentioned in the commit logs.  This is an edge
case that is hard to get into the release notes.

Now that you have told me about it, here is my normal criteria for
adding performance items to the release notes:

	Performance improvements are mentioned in the release notes if
	they are user-visible (e.g., new syntax) or significant enough
	to enable new workloads.

So, it seems there is no user-visible change, except it is faster.  Does
it enable new workloads?  A 3x speedup probably does.  Should this be a
pg_trgm item, with a description mentioning GIN in general, or should it
be a GIN item, perhaps mentioning pg_trgm?  Do you have any suggested
text and list of commits?

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Do not let urgent matters crowd out time for investment in the future.





^ permalink  raw  reply  [nested|flat] 129+ messages in thread

* Re: First draft of PG 19 release notes
@ 2026-04-16 16:45  Bruce Momjian <bruce@momjian.us>
  parent: Richard Guo <guofenglinux@gmail.com>
  0 siblings, 0 replies; 129+ messages in thread

From: Bruce Momjian @ 2026-04-16 16:45 UTC (permalink / raw)
  To: Richard Guo <guofenglinux@gmail.com>; +Cc: PostgreSQL-development <pgsql-hackers@lists.postgresql.org>

On Thu, Apr 16, 2026 at 04:49:37PM +0900, Richard Guo wrote:
> On Wed, Apr 15, 2026 at 10:19 AM Bruce Momjian <bruce@momjian.us> wrote:
> > I have completed the first draft of the PG 19 release notes:
> >
> >         https://www.postgresql.org/docs/devel/release-19.html
> 
> Thanks for putting in all this work!
> 
> The co-author is missing from this item:
> * Allow more LEFT JOINs to be converted to ANTI JOINs (Tender Wang)
> 
> Three items authored by me are under General Performance but should be
> under Optimizer, as they are planner-time expression transformations.
> I also fixed some wording issues in those items and one other
> Optimizer item.
> 
> Attached is the patch.

Great, patch applied.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Do not let urgent matters crowd out time for investment in the future.





^ permalink  raw  reply  [nested|flat] 129+ messages in thread

* Re: First draft of PG 19 release notes
@ 2026-04-17 14:40  David Geier <geidav.pg@gmail.com>
  parent: Bruce Momjian <bruce@momjian.us>
  0 siblings, 1 reply; 129+ messages in thread

From: David Geier @ 2026-04-17 14:40 UTC (permalink / raw)
  To: Bruce Momjian <bruce@momjian.us>; +Cc: PostgreSQL-development <pgsql-hackers@lists.postgresql.org>

On 16.04.2026 18:14, Bruce Momjian wrote:
>> How about also including the improvements we did for reducing GIN index
>> build times, see [1]? Not all patches have been committed yet but the
>> ones that got committed already make a meaningful difference.
>>
>> [1]
>> https://www.postgresql.org/message-id/flat/5d366878-2007-4d31-861e-19294b7a583b%40gmail.com
> 
> This is an interesting case.  First, I looked at the commit logs and
> didn't see anything talking about improving the speed of GIN index
> builds.  So then I looked at the first email in the thread and saw 3x
> improvement for pg_trgm, so I looked in the commit logs for pg_trgm and
> didn't see any speedup mentioned.
> 
> I then looked at the posted patches and this might be a case where there
> are a number of targeted improvements that didn't specify the larger
> goal, so there is no goal mentioned in the commit logs.  This is an edge
> case that is hard to get into the release notes.
> 
> Now that you have told me about it, here is my normal criteria for
> adding performance items to the release notes:
> 
> 	Performance improvements are mentioned in the release notes if
> 	they are user-visible (e.g., new syntax) or significant enough
> 	to enable new workloads.
> 
> So, it seems there is no user-visible change, except it is faster.  Does
> it enable new workloads?  A 3x speedup probably does.  Should this be a
> pg_trgm item, with a description mentioning GIN in general, or should it
> be a GIN item, perhaps mentioning pg_trgm?  Do you have any suggested
> text and list of commits?

Not all patches from the initial mail have been committed yet. Hence,
currently the speed up is less. However, once they got all committed
they would indeed open up new "use cases". For example, I know users
that don't add GIN indexes to very large tables because creating them
takes too long.

--
David Geier





^ permalink  raw  reply  [nested|flat] 129+ messages in thread

* Re: First draft of PG 19 release notes
@ 2026-04-17 14:44  Bruce Momjian <bruce@momjian.us>
  parent: David Geier <geidav.pg@gmail.com>
  0 siblings, 1 reply; 129+ messages in thread

From: Bruce Momjian @ 2026-04-17 14:44 UTC (permalink / raw)
  To: David Geier <geidav.pg@gmail.com>; +Cc: PostgreSQL-development <pgsql-hackers@lists.postgresql.org>

On Fri, Apr 17, 2026 at 04:40:09PM +0200, David Geier wrote:
> > Now that you have told me about it, here is my normal criteria for
> > adding performance items to the release notes:
> > 
> > 	Performance improvements are mentioned in the release notes if
> > 	they are user-visible (e.g., new syntax) or significant enough
> > 	to enable new workloads.
> > 
> > So, it seems there is no user-visible change, except it is faster.  Does
> > it enable new workloads?  A 3x speedup probably does.  Should this be a
> > pg_trgm item, with a description mentioning GIN in general, or should it
> > be a GIN item, perhaps mentioning pg_trgm?  Do you have any suggested
> > text and list of commits?
> 
> Not all patches from the initial mail have been committed yet. Hence,
> currently the speed up is less. However, once they got all committed
> they would indeed open up new "use cases". For example, I know users
> that don't add GIN indexes to very large tables because creating them
> takes too long.

Yes, GIN index creation has always been considered slow, so it is good
it is being worked on.  I wonder if we should just wait for it all to be
committed before adding it to the release notes, unless you want to
measure the improvement we have in PG 19.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Do not let urgent matters crowd out time for investment in the future.





^ permalink  raw  reply  [nested|flat] 129+ messages in thread

* Re: First draft of PG 19 release notes
@ 2026-04-19 11:27  David Geier <geidav.pg@gmail.com>
  parent: Bruce Momjian <bruce@momjian.us>
  0 siblings, 1 reply; 129+ messages in thread

From: David Geier @ 2026-04-19 11:27 UTC (permalink / raw)
  To: Bruce Momjian <bruce@momjian.us>; +Cc: PostgreSQL-development <pgsql-hackers@lists.postgresql.org>

>>> So, it seems there is no user-visible change, except it is faster.  Does
>>> it enable new workloads?  A 3x speedup probably does.  Should this be a
>>> pg_trgm item, with a description mentioning GIN in general, or should it
>>> be a GIN item, perhaps mentioning pg_trgm?  Do you have any suggested
>>> text and list of commits?
>>
>> Not all patches from the initial mail have been committed yet. Hence,
>> currently the speed up is less. However, once they got all committed
>> they would indeed open up new "use cases". For example, I know users
>> that don't add GIN indexes to very large tables because creating them
>> takes too long.
> 
> Yes, GIN index creation has always been considered slow, so it is good
> it is being worked on.  I wonder if we should just wait for it all to be
> committed before adding it to the release notes, unless you want to
> measure the improvement we have in PG 19.

I've measured with the same benchmark I used in the original thread [1].
With latest master the results are as follows:

Dataset  | REL_18_3   | master     | Speedup
---------|------------|------------|--------
movies   |  10,561 ms |   9,124 ms | 1.17x
lineitem | 263,523 ms | 234,605 ms | 1.12x

That's because three patches from the patchset haven't been committed
yet. Two of the three patches are the most impactful from the patchset.

[1]
https://www.postgresql.org/message-id/flat/5d366878-2007-4d31-861e-19294b7a583b%40gmail.com

--
David Geier





^ permalink  raw  reply  [nested|flat] 129+ messages in thread

* Re: First draft of PG 19 release notes
@ 2026-04-19 13:32  Bruce Momjian <bruce@momjian.us>
  parent: David Geier <geidav.pg@gmail.com>
  0 siblings, 1 reply; 129+ messages in thread

From: Bruce Momjian @ 2026-04-19 13:32 UTC (permalink / raw)
  To: David Geier <geidav.pg@gmail.com>; +Cc: PostgreSQL-development <pgsql-hackers@lists.postgresql.org>

On Sun, Apr 19, 2026 at 01:27:10PM +0200, David Geier wrote:
> >>> So, it seems there is no user-visible change, except it is faster.  Does
> >>> it enable new workloads?  A 3x speedup probably does.  Should this be a
> >>> pg_trgm item, with a description mentioning GIN in general, or should it
> >>> be a GIN item, perhaps mentioning pg_trgm?  Do you have any suggested
> >>> text and list of commits?
> >>
> >> Not all patches from the initial mail have been committed yet. Hence,
> >> currently the speed up is less. However, once they got all committed
> >> they would indeed open up new "use cases". For example, I know users
> >> that don't add GIN indexes to very large tables because creating them
> >> takes too long.
> > 
> > Yes, GIN index creation has always been considered slow, so it is good
> > it is being worked on.  I wonder if we should just wait for it all to be
> > committed before adding it to the release notes, unless you want to
> > measure the improvement we have in PG 19.
> 
> I've measured with the same benchmark I used in the original thread [1].
> With latest master the results are as follows:
> 
> Dataset  | REL_18_3   | master     | Speedup
> ---------|------------|------------|--------
> movies   |  10,561 ms |   9,124 ms | 1.17x
> lineitem | 263,523 ms | 234,605 ms | 1.12x
> 
> That's because three patches from the patchset haven't been committed
> yet. Two of the three patches are the most impactful from the patchset.

Okay, at +12-17%, so we should wait until all the patches are in to
mention this.  Thanks.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Do not let urgent matters crowd out time for investment in the future.





^ permalink  raw  reply  [nested|flat] 129+ messages in thread

* Re: First draft of PG 19 release notes
@ 2026-04-19 15:10  Andres Freund <andres@anarazel.de>
  parent: Bruce Momjian <bruce@momjian.us>
  0 siblings, 1 reply; 129+ messages in thread

From: Andres Freund @ 2026-04-19 15:10 UTC (permalink / raw)
  To: Bruce Momjian <bruce@momjian.us>; +Cc: David Geier <geidav.pg@gmail.com>; PostgreSQL-development <pgsql-hackers@lists.postgresql.org>

Hi,

On 2026-04-19 09:32:45 -0400, Bruce Momjian wrote:
> On Sun, Apr 19, 2026 at 01:27:10PM +0200, David Geier wrote:
> > >>> So, it seems there is no user-visible change, except it is faster.  Does
> > >>> it enable new workloads?  A 3x speedup probably does.  Should this be a
> > >>> pg_trgm item, with a description mentioning GIN in general, or should it
> > >>> be a GIN item, perhaps mentioning pg_trgm?  Do you have any suggested
> > >>> text and list of commits?
> > >>
> > >> Not all patches from the initial mail have been committed yet. Hence,
> > >> currently the speed up is less. However, once they got all committed
> > >> they would indeed open up new "use cases". For example, I know users
> > >> that don't add GIN indexes to very large tables because creating them
> > >> takes too long.
> > > 
> > > Yes, GIN index creation has always been considered slow, so it is good
> > > it is being worked on.  I wonder if we should just wait for it all to be
> > > committed before adding it to the release notes, unless you want to
> > > measure the improvement we have in PG 19.
> > 
> > I've measured with the same benchmark I used in the original thread [1].
> > With latest master the results are as follows:
> > 
> > Dataset  | REL_18_3   | master     | Speedup
> > ---------|------------|------------|--------
> > movies   |  10,561 ms |   9,124 ms | 1.17x
> > lineitem | 263,523 ms | 234,605 ms | 1.12x
> > 
> > That's because three patches from the patchset haven't been committed
> > yet. Two of the three patches are the most impactful from the patchset.
> 
> Okay, at +12-17%, so we should wait until all the patches are in to
> mention this.  Thanks.

That makes no sense to me.  It's a material improvement that could convince
people to upgrade.  Why would you not want to mention that, just because PG 20
might have further improvements? There *always* will be further potential
improvements.

Greetings,

Andres Freund





^ permalink  raw  reply  [nested|flat] 129+ messages in thread

* Re: First draft of PG 19 release notes
@ 2026-04-19 17:53  Bruce Momjian <bruce@momjian.us>
  parent: Andres Freund <andres@anarazel.de>
  0 siblings, 1 reply; 129+ messages in thread

From: Bruce Momjian @ 2026-04-19 17:53 UTC (permalink / raw)
  To: Andres Freund <andres@anarazel.de>; +Cc: David Geier <geidav.pg@gmail.com>; PostgreSQL-development <pgsql-hackers@lists.postgresql.org>

On Sun, Apr 19, 2026 at 11:10:40AM -0400, Andres Freund wrote:
> Hi,
> 
> On 2026-04-19 09:32:45 -0400, Bruce Momjian wrote:
> > On Sun, Apr 19, 2026 at 01:27:10PM +0200, David Geier wrote:
> > > >>> So, it seems there is no user-visible change, except it is faster.  Does
> > > >>> it enable new workloads?  A 3x speedup probably does.  Should this be a
> > > >>> pg_trgm item, with a description mentioning GIN in general, or should it
> > > >>> be a GIN item, perhaps mentioning pg_trgm?  Do you have any suggested
> > > >>> text and list of commits?
> > > >>
> > > >> Not all patches from the initial mail have been committed yet. Hence,
> > > >> currently the speed up is less. However, once they got all committed
> > > >> they would indeed open up new "use cases". For example, I know users
> > > >> that don't add GIN indexes to very large tables because creating them
> > > >> takes too long.
> > > > 
> > > > Yes, GIN index creation has always been considered slow, so it is good
> > > > it is being worked on.  I wonder if we should just wait for it all to be
> > > > committed before adding it to the release notes, unless you want to
> > > > measure the improvement we have in PG 19.
> > > 
> > > I've measured with the same benchmark I used in the original thread [1].
> > > With latest master the results are as follows:
> > > 
> > > Dataset  | REL_18_3   | master     | Speedup
> > > ---------|------------|------------|--------
> > > movies   |  10,561 ms |   9,124 ms | 1.17x
> > > lineitem | 263,523 ms | 234,605 ms | 1.12x
> > > 
> > > That's because three patches from the patchset haven't been committed
> > > yet. Two of the three patches are the most impactful from the patchset.
> > 
> > Okay, at +12-17%, so we should wait until all the patches are in to
> > mention this.  Thanks.
> 
> That makes no sense to me.  It's a material improvement that could convince
> people to upgrade.  Why would you not want to mention that, just because PG 20
> might have further improvements? There *always* will be further potential
> improvements.

The text I put in the wiki, which I have followed for years, says:

	https://wiki.postgresql.org/wiki/Creating_Major_Release_Notes
	Performance improvements are mentioned in the release notes if
	they are user-visible (e.g., new syntax) or significant enough
	to enable new workloads.

I didn't think +12-17% for an index build would enable new workloads. 
If you want to relitigate that, you are welcome to do so.  If this is
changed, it has to be done so consistently, not just for this item.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Do not let urgent matters crowd out time for investment in the future.





^ permalink  raw  reply  [nested|flat] 129+ messages in thread

* Re: First draft of PG 19 release notes
@ 2026-04-19 18:04  Andres Freund <andres@anarazel.de>
  parent: Bruce Momjian <bruce@momjian.us>
  0 siblings, 1 reply; 129+ messages in thread

From: Andres Freund @ 2026-04-19 18:04 UTC (permalink / raw)
  To: Bruce Momjian <bruce@momjian.us>; +Cc: David Geier <geidav.pg@gmail.com>; PostgreSQL-development <pgsql-hackers@lists.postgresql.org>

Hi,

On 2026-04-19 13:53:08 -0400, Bruce Momjian wrote:
> The text I put in the wiki, which I have followed for years, says:
>
> 	https://wiki.postgresql.org/wiki/Creating_Major_Release_Notes
> 	Performance improvements are mentioned in the release notes if
> 	they are user-visible (e.g., new syntax) or significant enough
> 	to enable new workloads.
>
> I didn't think +12-17% for an index build would enable new workloads.
> If you want to relitigate that, you are welcome to do so.  If this is
> changed, it has to be done so consistently, not just for this item.

Just about everyone has disagreed vehemently with you about this, in every of
the last 5 releases or so.  I don't think it's ok that you continue to ignore
that.

I find this policy so depressing that I stopped even opening the release
notes, just to preserve whatever semblance of sanity I possess.  I'm know I'm
not alone in that.

Greetings,

Andres Freund





^ permalink  raw  reply  [nested|flat] 129+ messages in thread

* Re: First draft of PG 19 release notes
@ 2026-04-19 18:36  Bruce Momjian <bruce@momjian.us>
  parent: Andres Freund <andres@anarazel.de>
  0 siblings, 1 reply; 129+ messages in thread

From: Bruce Momjian @ 2026-04-19 18:36 UTC (permalink / raw)
  To: Andres Freund <andres@anarazel.de>; +Cc: David Geier <geidav.pg@gmail.com>; PostgreSQL-development <pgsql-hackers@lists.postgresql.org>

On Sun, Apr 19, 2026 at 02:04:34PM -0400, Andres Freund wrote:
> Hi,
> 
> On 2026-04-19 13:53:08 -0400, Bruce Momjian wrote:
> > The text I put in the wiki, which I have followed for years, says:
> >
> > 	https://wiki.postgresql.org/wiki/Creating_Major_Release_Notes
> > 	Performance improvements are mentioned in the release notes if
> > 	they are user-visible (e.g., new syntax) or significant enough
> > 	to enable new workloads.
> >
> > I didn't think +12-17% for an index build would enable new workloads.
> > If you want to relitigate that, you are welcome to do so.  If this is
> > changed, it has to be done so consistently, not just for this item.
> 
> Just about everyone has disagreed vehemently with you about this, in every of
> the last 5 releases or so.  I don't think it's ok that you continue to ignore
> that.

That is not my recollection, and I thought I would have heard more about
it if that was the case.

> I find this policy so depressing that I stopped even opening the release
> notes, just to preserve whatever semblance of sanity I possess.  I'm know I'm
> not alone in that.

Well, I just merged the wiki text to explain that we have to consider
how much an item is of interest when adding it:

	While the major release notes include changes to the documented
	extension interface, it does not include all changes of interest
	to extension developers or Postgres forks because doing so would
	include too many items that would be uninteresting to the general
	audience.  Performance improvements are mentioned in the release
	notes if they are user-visible (e.g., new syntax) or significant
	enough to enable new workloads.

So, if you want to change this process, please feel free to get
agreement on new text that I can follow, or someone else can follow.

I have always hesitated to expand the list of items with concern that
general Postgres users will lose interest in reading it.  I have in mind
that the release notes are not for me or hackers subscribers to read.

I think we expanded the the list for optimizer changes.  Could we find a
way to do that more that would be readable?  I don't know.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Do not let urgent matters crowd out time for investment in the future.





^ permalink  raw  reply  [nested|flat] 129+ messages in thread

* Re: First draft of PG 19 release notes
@ 2026-04-19 19:25  Andres Freund <andres@anarazel.de>
  parent: Bruce Momjian <bruce@momjian.us>
  0 siblings, 1 reply; 129+ messages in thread

From: Andres Freund @ 2026-04-19 19:25 UTC (permalink / raw)
  To: Bruce Momjian <bruce@momjian.us>; +Cc: David Geier <geidav.pg@gmail.com>; PostgreSQL-development <pgsql-hackers@lists.postgresql.org>

On 2026-04-19 14:36:57 -0400, Bruce Momjian wrote:
> On Sun, Apr 19, 2026 at 02:04:34PM -0400, Andres Freund wrote:
> > Hi,
> > 
> > On 2026-04-19 13:53:08 -0400, Bruce Momjian wrote:
> > > The text I put in the wiki, which I have followed for years, says:
> > >
> > > 	https://wiki.postgresql.org/wiki/Creating_Major_Release_Notes
> > > 	Performance improvements are mentioned in the release notes if
> > > 	they are user-visible (e.g., new syntax) or significant enough
> > > 	to enable new workloads.
> > >
> > > I didn't think +12-17% for an index build would enable new workloads.
> > > If you want to relitigate that, you are welcome to do so.  If this is
> > > changed, it has to be done so consistently, not just for this item.
> > 
> > Just about everyone has disagreed vehemently with you about this, in every of
> > the last 5 releases or so.  I don't think it's ok that you continue to ignore
> > that.
> 
> That is not my recollection, and I thought I would have heard more about
> it if that was the case.

I don't know what to tell you. Just looking at emails to you with a subject
that contains release and a body that contains performance quickly unearthed:

Tom:
https://postgr.es/m/568104.1716520270@sss.pgh.pa.us

Jonathan:
https://postgr.es/m/29a7dd7b-cb55-4c3c-8eba-faeca222b10b@postgresql.org

Alvaro:
https://postgr.es/m/202405150838.sg5ddcexyyf4@alvherre.pgsql

David:
https://postgr.es/m/CAApHDvrun6b+cAj6bgb6_1irnu+t7GU_uCdj1XvMQsPT0KngkQ@mail.gmail.com

Melanie:
https://postgr.es/m/CAAKRu_YKDQG1qA-eRq+gf5uoXZ3s9Jm3af9k3yF7WdKr2eTqLA@mail.gmail.com

Joe:
https://postgr.es/m/c276a2e5-a7ef-410d-832e-6fe54137e86d@joeconway.com

Jelte:
https://postgr.es/m/CAGECzQTp5TW+YzihDdPDuZN6q_uNWL_iCi5uxN2AjGPLOJh=Mg@mail.gmail.com

Peter G:
https://postgr.es/m/CAH2-Wzkgyak_ni0u24r1v3nhM1gVfx68-7-ZX1yZB+zcojMdnw@mail.gmail.com

Robert:
https://postgr.es/m/CA+TgmobqYx=+1RDsD7w9r_pfTa-CgJ6_Aj0SNaA6UKHQGyT9vg@mail.gmail.com

Noah:
20180505061321.GA2832545@rfd.leadboat.com

me:
https://postgr.es/m/20240524175028.lul7tpbngjlemy7j@awork3.anarazel.de


That's just a small sample.  I think nearly everybody said so in multiple
releases.  The argument goes back to at least 9.5...




> > I find this policy so depressing that I stopped even opening the release
> > notes, just to preserve whatever semblance of sanity I possess.  I'm know I'm
> > not alone in that.
> 
> Well, I just merged the wiki text to explain that we have to consider
> how much an item is of interest when adding it:
> 
> 	While the major release notes include changes to the documented
> 	extension interface, it does not include all changes of interest
> 	to extension developers or Postgres forks because doing so would
> 	include too many items that would be uninteresting to the general
> 	audience.  Performance improvements are mentioned in the release
> 	notes if they are user-visible (e.g., new syntax) or significant
> 	enough to enable new workloads.

I think you're again documenting things as consensus for which there is not
concensus.


> So, if you want to change this process, please feel free to get
> agreement on new text that I can follow, or someone else can follow.

s/if they are user-visible (e.g., new syntax) or//
s/enough to enable new workloads//


> I have always hesitated to expand the list of items with concern that
> general Postgres users will lose interest in reading it.  I have in mind
> that the release notes are not for me or hackers subscribers to read.

Yes, which is precisely why they should be able to read the release notes to
see if an upgrade might address their performance issue. They can't
realistically be expected to read all commit messages or the list.


> I think we expanded the the list for optimizer changes.  Could we find a
> way to do that more that would be readable?  I don't know.

I don't think mentioning a few performance improvements when we do mention
things like "Modify psql backslash commands to show comments", "Allow the
search path to appear in the psql prompt via "%S", "Add IO wait events for
COPY FROM/TO on a pipe/file/program", ... makes a material negative
difference.

If we want to make the release notes easier to grasp, I could imagine that
giving each bullet point an icon indicating whether it's a feature, a
performance improvement, a behavioural change or such could make it easier to
scan.

Greetings,

Andres Freund





^ permalink  raw  reply  [nested|flat] 129+ messages in thread

* Re: First draft of PG 19 release notes
@ 2026-04-20 01:30  David Rowley <dgrowleyml@gmail.com>
  parent: Andres Freund <andres@anarazel.de>
  0 siblings, 1 reply; 129+ messages in thread

From: David Rowley @ 2026-04-20 01:30 UTC (permalink / raw)
  To: Andres Freund <andres@anarazel.de>; +Cc: Bruce Momjian <bruce@momjian.us>; David Geier <geidav.pg@gmail.com>; PostgreSQL-development <pgsql-hackers@lists.postgresql.org>

On Mon, 20 Apr 2026 at 07:25, Andres Freund <andres@anarazel.de> wrote:
>
> On 2026-04-19 14:36:57 -0400, Bruce Momjian wrote:
> > That is not my recollection, and I thought I would have heard more about
> > it if that was the case.
>
> I don't know what to tell you. Just looking at emails to you with a subject
> that contains release and a body that contains performance quickly unearthed:

> David:
> https://postgr.es/m/CAApHDvrun6b+cAj6bgb6_1irnu+t7GU_uCdj1XvMQsPT0KngkQ@mail.gmail.com

This isn't a "I told you so" comment, but I do feel that it's hard to
unsee the irony in the originally omitted item being discussed there
(tidstore), which in the end was the top-listed headline feature for
v17. I feel that was just too powerful a signal to how much others do
think this stuff is worthwhile mentioning.

> > I have always hesitated to expand the list of items with concern that
> > general Postgres users will lose interest in reading it.  I have in mind
> > that the release notes are not for me or hackers subscribers to read.

There is a "General Performance" section for this, so maybe people who
don't care about performance can skip these more easily.

I do agree that there is some threshold. Sometimes we do commit
patches which we know increases performance some way, but nobody
tested by how much. There are likely many of these, but one example
[1] that I don't think has any business on the release notes, but it
should help performance somehow/somewhere. It just might or might not
be measurable. Filtering out those seems good.

Maybe there's something committers can put in the commit message to
make it more obvious which commits matter by referencing some actual
performance numbers that were published that showed a definitive
speedup (not just a measurment of noise). I do expect that it's a
fairly horrible job if we're going to ask Bruce to trawl each thread
to find what performance numbers were posted. In the past I've tried
to list some example numbers in commit messages to help Bruce (e.g.
final paragraph in [2] and [3]). I'm not sure if it does help, or if
there's something better that could be done instead.

David

[1] https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=49ce41810faca2722424b3d8fabda79bf4902...
[2] https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=c456e39113809376f6604e720910ccd24e18e...
[3] https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=58a359e585d0281ecab4d34cab9869e7eb4e4...





^ permalink  raw  reply  [nested|flat] 129+ messages in thread

* Re: First draft of PG 19 release notes
@ 2026-04-20 09:10  Bruce Momjian <bruce@momjian.us>
  parent: David Rowley <dgrowleyml@gmail.com>
  0 siblings, 1 reply; 129+ messages in thread

From: Bruce Momjian @ 2026-04-20 09:10 UTC (permalink / raw)
  To: David Rowley <dgrowleyml@gmail.com>; +Cc: Andres Freund <andres@anarazel.de>; David Geier <geidav.pg@gmail.com>; PostgreSQL-development <pgsql-hackers@lists.postgresql.org>

On Mon, Apr 20, 2026 at 01:30:25PM +1200, David Rowley wrote:
> Maybe there's something committers can put in the commit message to
> make it more obvious which commits matter by referencing some actual
> performance numbers that were published that showed a definitive
> speedup (not just a measurement of noise). I do expect that it's a
> fairly horrible job if we're going to ask Bruce to trawl each thread
> to find what performance numbers were posted. In the past I've tried
> to list some example numbers in commit messages to help Bruce (e.g.
> final paragraph in [2] and [3]). I'm not sure if it does help, or if
> there's something better that could be done instead.

In that thread from PG 17, I said:

https://www.postgresql.org/message-id/ZlKaHOM8HYLy9nCY%40momjian.us

> Well, let's start with a new section for PG 17 that lists these.  Is it
> 20 items, 50, or 150?  I have no idea, but without the user-visible
> filter, I am unable to determine what not-included performance features
> are worthy of the release notes.
> 
> Can someone do that?  There is no reason other committers can't change
> the release notes.  Yes, I realize we are looking for a consistent
> voice, but the new section can probably have its own style, and I can
> make adjustments if desired.
> 
> Also, I think this has gone unaddressed so long because if we skip a
> user-visible change, users complain, but I don't remember anyone
> complaining about skipped performance changes.

So, what is the filter I am supposed to use?  We even have a patch that,
in aggregate, increases performance by 12-17%.  Is that under or over
the threadshold to be included?  I have no idea.  And, even if we agree
on a number, how do I handle commits with no numbers;  this commit
didn't have a number.

Just like with the co-authored-by, I need rules.  I thought I got
agreement on the co-authored-by rules in January 2025 because no one
objected, only to learn recently that many didn't like it, and we
changed the rules, and I used those new rules for PG 19.

I can follow the rules on the wiki:

	https://wiki.postgresql.org/wiki/Creating_Major_Release_Notes
	While the major release notes include changes to the documented
	extension interface, it does not include all changes of interest
	to extension developers or Postgres forks because doing so would
	include too many items that would be uninteresting to the general
	audience.  Similarly, performance improvements are not mentioned in
	the release notes unless they are user-visible (e.g., new syntax)
	or significant enough to enable new workloads.

I can't follow rules that require me to consistently identify if a patch
is a performance improvement, and if it is significant enough for the
release notes.  If someone else can do that, please go ahead and stop
blaming me for something I can't do.  I thought if it was easy, someone
else since PG 17 would have either given me rules or done it.

Can committers mention when they want something to be included in the
release notes?  What we can do is to have all the hackers point out the
missing items after I done creating the release notes, as messy as that
is.

One thing we can easily do is to add text to the release notes stating,
"This release includes minor performance improvements that are too
numerous to mention."

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Do not let urgent matters crowd out time for investment in the future.





^ permalink  raw  reply  [nested|flat] 129+ messages in thread

* Re: First draft of PG 19 release notes
@ 2026-04-20 10:07  shammat@gmx.net
  parent: Bruce Momjian <bruce@momjian.us>
  25 siblings, 1 reply; 129+ messages in thread

From: shammat@gmx.net @ 2026-04-20 10:07 UTC (permalink / raw)
  To: pgsql-hackers@lists.postgresql.org

Bruce Momjian schrieb am 15.04.2026 um 03:18:
> I have completed the first draft of the PG 19 release notes:
> 
> 	https://www.postgresql.org/docs/devel/release-19.html
> 
> The feature count is 212.  The recent average is 200:
> 
> 	https://momjian.us/main/writings/pgsql/missing.pdf#page=3
> 
> I will create a wiki page to explain my methods used to create this
> because, someday, someone else will need to do this.
> 
> I am traveling April 19 to May 7, so I might not be able to make quick
> adjustments based on feedback.  Another committer can handle them, or
> you can wait for me to get to it.
> 


"Allow casts between bytea and uuid date types"

I think that should be "data" types? 









^ permalink  raw  reply  [nested|flat] 129+ messages in thread

* Re: First draft of PG 19 release notes
@ 2026-04-20 10:40  David Rowley <dgrowleyml@gmail.com>
  parent: Bruce Momjian <bruce@momjian.us>
  0 siblings, 2 replies; 129+ messages in thread

From: David Rowley @ 2026-04-20 10:40 UTC (permalink / raw)
  To: Bruce Momjian <bruce@momjian.us>; +Cc: Andres Freund <andres@anarazel.de>; David Geier <geidav.pg@gmail.com>; PostgreSQL-development <pgsql-hackers@lists.postgresql.org>

On Mon, 20 Apr 2026 at 21:10, Bruce Momjian <bruce@momjian.us> wrote:
> In that thread from PG 17, I said:
>
> https://www.postgresql.org/message-id/ZlKaHOM8HYLy9nCY%40momjian.us
>
> > Well, let's start with a new section for PG 17 that lists these.  Is it
> > 20 items, 50, or 150?  I have no idea, but without the user-visible
> > filter, I am unable to determine what not-included performance features
> > are worthy of the release notes.

I imagine it's easier to prune away items that are not interesting
enough than to add ones that were skipped. Unless we get visibility of
ones that you skipped, it requires someone else to notice something is
missing (probably their own work), or it requires a complete parse of
all commits in the release.

> So, what is the filter I am supposed to use?  We even have a patch that,
> in aggregate, increases performance by 12-17%.  Is that under or over
> the threadshold to be included?  I have no idea.  And, even if we agree
> on a number, how do I handle commits with no numbers;  this commit
> didn't have a number.

That's going to be tricky to define. 2x performance increase in
something like initdb isn't going to be nearly as interesting to an
end user as making joins or aggregation go twice as fast. Maybe it
would be worth putting temporary tags on items that there are no
obvious performance numbers for to tell the author or committer that
you need proof, otherwise the item might disappear. For items that
might be more borderline worth adding, maybe those could also get
added and tagged to trigger some debate as to if they're worth keeping
around. In the end, we might see what it is you see with the bloated
release notes. You might find you get more agreement to remove things.
That's seldom requested with the current method. It seems reasonable
that not many people can sympathise with the "there are too many
items" problem, as by the time the notes go public, they're already
trimmed down to a manageable number. We might find that we all agree
on more things if the pruning is done more publicly.

> I can't follow rules that require me to consistently identify if a patch
> is a performance improvement, and if it is significant enough for the
> release notes.  If someone else can do that, please go ahead and stop
> blaming me for something I can't do.  I thought if it was easy, someone
> else since PG 17 would have either given me rules or done it.

I don't think anyone expects you to do anything that makes this job
harder than it already.  I expect a careful process change could make
this job easier for you.

> Can committers mention when they want something to be included in the
> release notes?  What we can do is to have all the hackers point out the
> missing items after I done creating the release notes, as messy as that
> is.

I wondered if the job could be made easier if we were to tag fixup
commits for commits that fix some recent feature commit. You could
pretty much ignore every single one of those for the release notes. If
that fixup information was more structured, it might also be very
interesting.

> One thing we can easily do is to add text to the release notes stating,
> "This release includes minor performance improvements that are too
> numerous to mention."

If the WIP draft contained the items of lesser importance, we might be
able to do some aggregation of those into something meaningful enough.
It might be much easier for people closer to the particular items to
aggregate them than it is for a single person to do it for all
commits. I'm aware that you already do quite a bit of this aggregation
already.

David





^ permalink  raw  reply  [nested|flat] 129+ messages in thread

* Re: First draft of PG 19 release notes
@ 2026-04-20 11:15  Bruce Momjian <bruce@momjian.us>
  parent: shammat@gmx.net
  0 siblings, 0 replies; 129+ messages in thread

From: Bruce Momjian @ 2026-04-20 11:15 UTC (permalink / raw)
  To: shammat@gmx.net; +Cc: pgsql-hackers@lists.postgresql.org

On Mon, Apr 20, 2026 at 12:07:55PM +0200, shammat@gmx.net wrote:
> Bruce Momjian schrieb am 15.04.2026 um 03:18:
> > I have completed the first draft of the PG 19 release notes:
> > 
> > 	https://www.postgresql.org/docs/devel/release-19.html
> > 
> > The feature count is 212.  The recent average is 200:
> > 
> > 	https://momjian.us/main/writings/pgsql/missing.pdf#page=3
> > 
> > I will create a wiki page to explain my methods used to create this
> > because, someday, someone else will need to do this.
> > 
> > I am traveling April 19 to May 7, so I might not be able to make quick
> > adjustments based on feedback.  Another committer can handle them, or
> > you can wait for me to get to it.
> > 
> 
> 
> "Allow casts between bytea and uuid date types"
> 
> I think that should be "data" types? 

Yes, fixed thanks.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Do not let urgent matters crowd out time for investment in the future.





^ permalink  raw  reply  [nested|flat] 129+ messages in thread

* Re: First draft of PG 19 release notes
@ 2026-04-20 13:03  Xuneng Zhou <xunengzhou@gmail.com>
  parent: Bruce Momjian <bruce@momjian.us>
  25 siblings, 1 reply; 129+ messages in thread

From: Xuneng Zhou @ 2026-04-20 13:03 UTC (permalink / raw)
  To: Bruce Momjian <bruce@momjian.us>; +Cc: PostgreSQL-development <pgsql-hackers@lists.postgresql.org>

Hi Bruce,

On Wed, Apr 15, 2026 at 9:19 AM Bruce Momjian <bruce@momjian.us> wrote:
>
> I have completed the first draft of the PG 19 release notes:
>
>         https://www.postgresql.org/docs/devel/release-19.html
>
> The feature count is 212.  The recent average is 200:
>
>         https://momjian.us/main/writings/pgsql/missing.pdf#page=3
>
> I will create a wiki page to explain my methods used to create this
> because, someday, someone else will need to do this.
>
> I am traveling April 19 to May 7, so I might not be able to make quick
> adjustments based on feedback.  Another committer can handle them, or
> you can wait for me to get to it.

Thanks for working on the draft. Here're some comments for it:

1) Improve performance of pgstattuple by using streaming reads

There are two related commits that improve the performance of
pgstattuple. The current hyperlink references [1]; would it make sense
to include [2] too?

[1] https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=213f0079b
[2] https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=ae58189a4d523f0156ebe30f4534180555669...


2) Additionally, would this[3] be something worth mentioning in the
General Performance section? The improvement looks fairly big.

[3] https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=6c228755add8f0714677440d53a160f9ed332...


3) Allow standbys to wait for LSN values to be replayed via WAIT FOR
As for this feature, the follow-up commit[4] extends the WAIT FOR
command to support waiting for flush and write operations. Is it
helpful for users to be aware of these use cases as well?

[4] https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=49a181b5d634340fcfb7c762c387c03f64053...

Thanks!

-- 
Best,
Xuneng





^ permalink  raw  reply  [nested|flat] 129+ messages in thread

* Re: First draft of PG 19 release notes
@ 2026-04-20 16:12  Bruce Momjian <bruce@momjian.us>
  parent: David Rowley <dgrowleyml@gmail.com>
  1 sibling, 1 reply; 129+ messages in thread

From: Bruce Momjian @ 2026-04-20 16:12 UTC (permalink / raw)
  To: David Rowley <dgrowleyml@gmail.com>; +Cc: Andres Freund <andres@anarazel.de>; David Geier <geidav.pg@gmail.com>; PostgreSQL-development <pgsql-hackers@lists.postgresql.org>

On Mon, Apr 20, 2026 at 10:40:13PM +1200, David Rowley wrote:
> That's going to be tricky to define. 2x performance increase in
> something like initdb isn't going to be nearly as interesting to an
> end user as making joins or aggregation go twice as fast. Maybe it
> would be worth putting temporary tags on items that there are no
> obvious performance numbers for to tell the author or committer that
> you need proof, otherwise the item might disappear. For items that
> might be more borderline worth adding, maybe those could also get
> added and tagged to trigger some debate as to if they're worth keeping
> around. In the end, we might see what it is you see with the bloated
> release notes. You might find you get more agreement to remove things.
> That's seldom requested with the current method. It seems reasonable
> that not many people can sympathise with the "there are too many
> items" problem, as by the time the notes go public, they're already
> trimmed down to a manageable number. We might find that we all agree
> on more things if the pruning is done more publicly.

So, these are not really rules, but a suggestion to just include more
and we can trim.  I see several problems with that:

1.  Researching and writing each item is what takes the most time, so it
could double my time to do this, which is fine if there were not other
problems.

2.  I don't think people will be motived to remove items, partly because
they might not want to upset anyone, and partly because they might
assume everyone else knows more.  This could lead to the item count
doubling, not because we want all those items but because we can't trim,
and I would be embarrassed to be part of that and would probably stop
being involved.

3.  My guess of what to add would be very poor.  I can mostly guess new
workload performance items, but once it gets more granular than that, I
would guess poorly and don't want to field complaints about my poor
guesses.

I asked in the PG 17 thread for someone to create a list of missing
items, and that was mostly successful.  Another approach would be for me
to create a document with the git detail of all commits I didn't include
--- that is easy to do since I have the commit hashes in the XML files,
and people can then look at that and tell me which commits need to be
added.

It is only April 20.  We still have time for someone to start from
scratch and make a new version.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Do not let urgent matters crowd out time for investment in the future.





^ permalink  raw  reply  [nested|flat] 129+ messages in thread

* Re: First draft of PG 19 release notes
@ 2026-04-21 12:24  Etsuro Fujita <etsuro.fujita@gmail.com>
  parent: Bruce Momjian <bruce@momjian.us>
  25 siblings, 1 reply; 129+ messages in thread

From: Etsuro Fujita @ 2026-04-21 12:24 UTC (permalink / raw)
  To: Bruce Momjian <bruce@momjian.us>; +Cc: PostgreSQL-development <pgsql-hackers@lists.postgresql.org>

On Wed, Apr 15, 2026 at 10:19 AM Bruce Momjian <bruce@momjian.us> wrote:
> I have completed the first draft of the PG 19 release notes:
>
>         https://www.postgresql.org/docs/devel/release-19.html

Thank you!

"Allow the retrieval of statistics from foreign data wrapper servers
(Corey Huinker, Etsuro Fujita)"

This is mentioned in the Additional Modules section, presumably
because it was supported in postgres_fdw, but it isn't limited to
postgres_fdw, so we should move it to the General Performance section?

Best regards,
Etsuro Fujita





^ permalink  raw  reply  [nested|flat] 129+ messages in thread

* Re: First draft of PG 19 release notes
@ 2026-04-21 15:52  Andres Freund <andres@anarazel.de>
  parent: Bruce Momjian <bruce@momjian.us>
  0 siblings, 2 replies; 129+ messages in thread

From: Andres Freund @ 2026-04-21 15:52 UTC (permalink / raw)
  To: Bruce Momjian <bruce@momjian.us>; +Cc: David Rowley <dgrowleyml@gmail.com>; David Geier <geidav.pg@gmail.com>; PostgreSQL-development <pgsql-hackers@lists.postgresql.org>

Hi,

On 2026-04-20 12:12:07 -0400, Bruce Momjian wrote:
> On Mon, Apr 20, 2026 at 10:40:13PM +1200, David Rowley wrote:
> > That's going to be tricky to define. 2x performance increase in
> > something like initdb isn't going to be nearly as interesting to an
> > end user as making joins or aggregation go twice as fast. Maybe it
> > would be worth putting temporary tags on items that there are no
> > obvious performance numbers for to tell the author or committer that
> > you need proof, otherwise the item might disappear. For items that
> > might be more borderline worth adding, maybe those could also get
> > added and tagged to trigger some debate as to if they're worth keeping
> > around. In the end, we might see what it is you see with the bloated
> > release notes. You might find you get more agreement to remove things.
> > That's seldom requested with the current method. It seems reasonable
> > that not many people can sympathise with the "there are too many
> > items" problem, as by the time the notes go public, they're already
> > trimmed down to a manageable number. We might find that we all agree
> > on more things if the pruning is done more publicly.
> 
> So, these are not really rules, but a suggestion to just include more
> and we can trim.  I see several problems with that:
> 
> 1.  Researching and writing each item is what takes the most time, so it
> could double my time to do this, which is fine if there were not other
> problems.

FWIW, I think it's totally fine if you say that you don't want to do the work
to formulate performance improvement release note entries.  It's a lot of work
to curate the release notes, it makes sense to split the work up.

It's just that the answer to proposing listing certain performance
improvements shouldn't be that we don't include them as a matter of policy.


> It is only April 20.  We still have time for someone to start from
> scratch and make a new version.

I don't see any need to start from scratch! That'd be foolish imo, it's a lot
of work to get to this point.

Greetings,

Andres Freund





^ permalink  raw  reply  [nested|flat] 129+ messages in thread

* Re: First draft of PG 19 release notes
@ 2026-04-21 20:18  Bruce Momjian <bruce@momjian.us>
  parent: David Rowley <dgrowleyml@gmail.com>
  1 sibling, 1 reply; 129+ messages in thread

From: Bruce Momjian @ 2026-04-21 20:18 UTC (permalink / raw)
  To: David Rowley <dgrowleyml@gmail.com>; +Cc: Andres Freund <andres@anarazel.de>; David Geier <geidav.pg@gmail.com>; PostgreSQL-development <pgsql-hackers@lists.postgresql.org>

On Mon, Apr 20, 2026 at 10:40:13PM +1200, David Rowley wrote:
> > I can't follow rules that require me to consistently identify if a patch
> > is a performance improvement, and if it is significant enough for the
> > release notes.  If someone else can do that, please go ahead and stop
> > blaming me for something I can't do.  I thought if it was easy, someone
> > else since PG 17 would have either given me rules or done it.
> 
> I don't think anyone expects you to do anything that makes this job
> harder than it already.  I expect a careful process change could make
> this job easier for you.
> 
> > Can committers mention when they want something to be included in the
> > release notes?  What we can do is to have all the hackers point out the
> > missing items after I done creating the release notes, as messy as that
> > is.
> 
> I wondered if the job could be made easier if we were to tag fixup
> commits for commits that fix some recent feature commit. You could
> pretty much ignore every single one of those for the release notes. If
> that fixup information was more structured, it might also be very
> interesting.
> 
> > One thing we can easily do is to add text to the release notes stating,
> > "This release includes minor performance improvements that are too
> > numerous to mention."
> 
> If the WIP draft contained the items of lesser importance, we might be
> able to do some aggregation of those into something meaningful enough.
> It might be much easier for people closer to the particular items to
> aggregate them than it is for a single person to do it for all
> commits. I'm aware that you already do quite a bit of this aggregation
> already.

I had some more time to think about the items you list above.  My first
reaction was that it wasn't workable, but I then realized it is not
workable because you can't do this level of analysis once the release
note items are written.  This idea of aggregating items and getting
people to choose items makes a lot of sense if we are using a list of
commits with git commit text that were not included already.

Let me work on creating such a list and we will see how it goes.  I am
traveling now so it will be delayed.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Do not let urgent matters crowd out time for investment in the future.





^ permalink  raw  reply  [nested|flat] 129+ messages in thread

* Re: First draft of PG 19 release notes
@ 2026-04-21 20:28  Bruce Momjian <bruce@momjian.us>
  parent: Andres Freund <andres@anarazel.de>
  1 sibling, 0 replies; 129+ messages in thread

From: Bruce Momjian @ 2026-04-21 20:28 UTC (permalink / raw)
  To: Andres Freund <andres@anarazel.de>; +Cc: David Rowley <dgrowleyml@gmail.com>; David Geier <geidav.pg@gmail.com>; PostgreSQL-development <pgsql-hackers@lists.postgresql.org>

On Tue, Apr 21, 2026 at 11:52:37AM -0400, Andres Freund wrote:
> On 2026-04-20 12:12:07 -0400, Bruce Momjian wrote:
> > So, these are not really rules, but a suggestion to just include more
> > and we can trim.  I see several problems with that:
> > 
> > 1.  Researching and writing each item is what takes the most time, so it
> > could double my time to do this, which is fine if there were not other
> > problems.
> 
> FWIW, I think it's totally fine if you say that you don't want to do the work
> to formulate performance improvement release note entries.  It's a lot of work
> to curate the release notes, it makes sense to split the work up.

When people complained about missing optimizer improvements, I was able
to add them by referencing the plan changes they effect, with the
assumption that they understand plan types.  For lower-level performance
improvements, it is nearly impossible for me to explain the items in a
way that references something the reader will understand.  Saying "widget
X is faster" when the user has no idea what X is just isn't useful
information for them, and I can't even explain widget X in a brief,
user-relatable way.  It is this fundamental issue that has prevented me
from even trying.

In summary, I was only able to do the optimizer additions by referencing
plan types --- if I didn't assume users understand plan types, adding
the optimizer issues would also have been impossible for me.  I think
David Rowley's idea of rolling up performance improvements into a single
release note entry that is relatable is a great idea, but something I am
incapable of doing without a lot of help.  Giving a list of commits and
git details might allow others to create text for such items.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Do not let urgent matters crowd out time for investment in the future.





^ permalink  raw  reply  [nested|flat] 129+ messages in thread

* Re: First draft of PG 19 release notes
@ 2026-04-21 20:41  Bruce Momjian <bruce@momjian.us>
  parent: Andres Freund <andres@anarazel.de>
  1 sibling, 0 replies; 129+ messages in thread

From: Bruce Momjian @ 2026-04-21 20:41 UTC (permalink / raw)
  To: Andres Freund <andres@anarazel.de>; +Cc: David Rowley <dgrowleyml@gmail.com>; David Geier <geidav.pg@gmail.com>; PostgreSQL-development <pgsql-hackers@lists.postgresql.org>

On Tue, Apr 21, 2026 at 11:52:37AM -0400, Andres Freund wrote:
> FWIW, I think it's totally fine if you say that you don't want to do the work
> to formulate performance improvement release note entries.  It's a lot of work
> to curate the release notes, it makes sense to split the work up.
> 
> It's just that the answer to proposing listing certain performance
> improvements shouldn't be that we don't include them as a matter of policy.

I am fine with listing anything, as long as it is effective and useful
to the reader.  I explained in my recent email why I considered that to
be very hard for performance items, but with help I think it can be
achieved.  New optimizer items are a good example --- we reference plan
types.  I need help in how other items can have similar effectiveness.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Do not let urgent matters crowd out time for investment in the future.





^ permalink  raw  reply  [nested|flat] 129+ messages in thread

* Re: First draft of PG 19 release notes
@ 2026-04-21 21:17  Bruce Momjian <bruce@momjian.us>
  parent: Bruce Momjian <bruce@momjian.us>
  0 siblings, 1 reply; 129+ messages in thread

From: Bruce Momjian @ 2026-04-21 21:17 UTC (permalink / raw)
  To: David Rowley <dgrowleyml@gmail.com>; +Cc: Andres Freund <andres@anarazel.de>; David Geier <geidav.pg@gmail.com>; PostgreSQL-development <pgsql-hackers@lists.postgresql.org>

On Tue, Apr 21, 2026 at 04:18:40PM -0400, Bruce Momjian wrote:
> Let me work on creating such a list and we will see how it goes.  I am
> traveling now so it will be delayed.

That was easy with awk, so done and attached.  There are 1556 commits
from the start of PG 19 to the AS OF date of the release notes that I
did not include in the release notes.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Do not let urgent matters crowd out time for investment in the future.

Attachments:

  [application/gzip] missing.gz (408.4K, ../../aefpWTbXj65tUNDQ@momjian.us/2-missing.gz)
  download

^ permalink  raw  reply  [nested|flat] 129+ messages in thread

* Re: First draft of PG 19 release notes
@ 2026-04-22 03:10  jian he <jian.universality@gmail.com>
  parent: Bruce Momjian <bruce@momjian.us>
  25 siblings, 1 reply; 129+ messages in thread

From: jian he @ 2026-04-22 03:10 UTC (permalink / raw)
  To: Bruce Momjian <bruce@momjian.us>; +Cc: PostgreSQL-development <pgsql-hackers@lists.postgresql.org>

On Wed, Apr 15, 2026 at 9:19 AM Bruce Momjian <bruce@momjian.us> wrote:
>
> I have completed the first draft of the PG 19 release notes:
>
>         https://www.postgresql.org/docs/devel/release-19.html
>

Change FDW function prototypes to use uint* instead of bit* typedefs
(Nathan Bossart) §
This commit doesn't seem related to FDW?

Allow btree_gin to match partial qualifications (Tom Lane) § §
I don't understand "partial qualifications", the commit seems more
about "cross type operators".

https://git.postgresql.org/cgit/postgresql.git/commit/?id=999f172d
Can this also be added to the release notes?

Do you think this
(https://git.postgresql.org/cgit/postgresql.git/commit/?id=00c025a001170979e99706ce746f75fcc615761d)
worth add to the release notes?

Before commit:
https://www.postgresql.org/docs/current/functions-matching.html#FUNCTIONS-POSIX-REGEXP
After commit:
https://www.postgresql.org/docs/devel/functions-matching.html#FUNCTIONS-POSIX-LIST



--
jian
https://www.enterprisedb.com/





^ permalink  raw  reply  [nested|flat] 129+ messages in thread

* Re: First draft of PG 19 release notes
@ 2026-04-22 07:11  Bruce Momjian <bruce@momjian.us>
  parent: Bruce Momjian <bruce@momjian.us>
  0 siblings, 1 reply; 129+ messages in thread

From: Bruce Momjian @ 2026-04-22 07:11 UTC (permalink / raw)
  To: David Rowley <dgrowleyml@gmail.com>; +Cc: Andres Freund <andres@anarazel.de>; David Geier <geidav.pg@gmail.com>; PostgreSQL-development <pgsql-hackers@lists.postgresql.org>

On Tue, Apr 21, 2026 at 05:17:13PM -0400, Bruce Momjian wrote:
> On Tue, Apr 21, 2026 at 04:18:40PM -0400, Bruce Momjian wrote:
> > Let me work on creating such a list and we will see how it goes.  I am
> > traveling now so it will be delayed.
> 
> That was easy with awk, so done and attached.  There are 1556 commits
> from the start of PG 19 to the AS OF date of the release notes that I
> did not include in the release notes.

Here is a better version with the "[DOC]" marker I use.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Do not let urgent matters crowd out time for investment in the future.

Attachments:

  [application/gzip] missing_doc.gz (408.5K, ../../aeh0m8XSP3k3T_L6@momjian.us/2-missing_doc.gz)
  download

^ permalink  raw  reply  [nested|flat] 129+ messages in thread

* Re: First draft of PG 19 release notes
@ 2026-04-23 15:10  Bruce Momjian <bruce@momjian.us>
  parent: Bruce Momjian <bruce@momjian.us>
  0 siblings, 1 reply; 129+ messages in thread

From: Bruce Momjian @ 2026-04-23 15:10 UTC (permalink / raw)
  To: David Rowley <dgrowleyml@gmail.com>; +Cc: Andres Freund <andres@anarazel.de>; David Geier <geidav.pg@gmail.com>; PostgreSQL-development <pgsql-hackers@lists.postgresql.org>

On Wed, Apr 22, 2026 at 03:11:23AM -0400, Bruce Momjian wrote:
> On Tue, Apr 21, 2026 at 05:17:13PM -0400, Bruce Momjian wrote:
> > On Tue, Apr 21, 2026 at 04:18:40PM -0400, Bruce Momjian wrote:
> > > Let me work on creating such a list and we will see how it goes.  I am
> > > traveling now so it will be delayed.
> > 
> > That was easy with awk, so done and attached.  There are 1556 commits
> > from the start of PG 19 to the AS OF date of the release notes that I
> > did not include in the release notes.
> 
> Here is a better version with the "[DOC]" marker I use.

I documented how I created this "excluded commits" list as item 12 here:

	https://wiki.postgresql.org/wiki/Creating_Major_Release_Notes

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Do not let urgent matters crowd out time for investment in the future.





^ permalink  raw  reply  [nested|flat] 129+ messages in thread

* Re: First draft of PG 19 release notes
@ 2026-04-30 07:08  Andreas Karlsson <andreas@proxel.se>
  parent: Bruce Momjian <bruce@momjian.us>
  25 siblings, 1 reply; 129+ messages in thread

From: Andreas Karlsson @ 2026-04-30 07:08 UTC (permalink / raw)
  To: Bruce Momjian <bruce@momjian.us>; PostgreSQL-development <pgsql-hackers@lists.postgresql.org>

On 4/15/26 3:18 AM, Bruce Momjian wrote:
> I have completed the first draft of the PG 19 release notes:

Thanks!

I noticed that two of my performance patches were not included in the 
release notes and I personally think one of them belongs in the release 
notes while other not.

The one I think belongs is the one below since it it really results in 
major speedups of lower(), upper(), initcap() and casefold() on ICU with 
UTF-8. Not having to convert from UTF-8 to UTF-32 and back is often a 
major speedup.

commit c4ff35f10441de7dbed4e87737bca205dcca698e
Author: Jeff Davis <jdavis@postgresql.org>
Date:   Tue Jan 6 14:09:07 2026 -0800

     ICU: use UTF8-optimized case conversion API

     Initializes a UCaseMap object once for use across calls, and uses
     UTF8-optimized APIs.

     Author: Andreas Karlsson <andreas@proxel.se>
     Reviewed-by: zengman <zengman@halodbtech.com>
     Discussion: 
https://postgr.es/m/5a010b27-8ed9-4739-86fe-1562b07ba564@proxel.se

-- 
Andreas Karlsson
Percona






^ permalink  raw  reply  [nested|flat] 129+ messages in thread

* Re: First draft of PG 19 release notes
@ 2026-04-30 07:16  Andreas Karlsson <andreas@proxel.se>
  parent: Andreas Karlsson <andreas@proxel.se>
  0 siblings, 1 reply; 129+ messages in thread

From: Andreas Karlsson @ 2026-04-30 07:16 UTC (permalink / raw)
  To: Bruce Momjian <bruce@momjian.us>; PostgreSQL-development <pgsql-hackers@lists.postgresql.org>

On 4/30/26 9:08 AM, Andreas Karlsson wrote:
> I noticed that two of my performance patches were not included in the 
> release notes and I personally think one of them belongs in the release 
> notes while other not.
> 
> The one I think belongs is the one below since it it really results in 
> major speedups of lower(), upper(), initcap() and casefold() on ICU with 
> UTF-8. Not having to convert from UTF-8 to UTF-32 and back is often a 
> major speedup.

Saw the big discussion on performance improvements if they should be 
included or not. So I will just leave this alone. :)

-- 
Andreas Karlsson
Percona






^ permalink  raw  reply  [nested|flat] 129+ messages in thread

* Re: First draft of PG 19 release notes
@ 2026-05-01 01:16  Richard Guo <guofenglinux@gmail.com>
  parent: Bruce Momjian <bruce@momjian.us>
  25 siblings, 1 reply; 129+ messages in thread

From: Richard Guo @ 2026-05-01 01:16 UTC (permalink / raw)
  To: Bruce Momjian <bruce@momjian.us>; +Cc: PostgreSQL-development <pgsql-hackers@lists.postgresql.org>

On Wed, Apr 15, 2026 at 10:19 AM Bruce Momjian <bruce@momjian.us> wrote:
> I have completed the first draft of the PG 19 release notes:
>
>         https://www.postgresql.org/docs/devel/release-19.html

I just committed 8d829f5a0 to fix JSON_ARRAY(subquery) to return an
empty JSON array instead of NULL over an empty result set, per the
SQL/JSON standard.  Since this is a user-visible behavior change, we
need to add an item to the v19 migration section to call it out.

Suggested entry:

 - Make JSON_ARRAY(query_expression) return an empty JSON array when
   the subquery returns no rows (Richard Guo)

   Previously, an empty result set produced NULL.  This corrects the
   behavior to match the SQL/JSON standard.  Application code that
   relied on the previous NULL behavior may need to be updated.

- Richard





^ permalink  raw  reply  [nested|flat] 129+ messages in thread

* RE: First draft of PG 19 release notes
@ 2026-05-01 13:24  Phil Florent <philflorent@hotmail.com>
  parent: Andreas Karlsson <andreas@proxel.se>
  0 siblings, 1 reply; 129+ messages in thread

From: Phil Florent @ 2026-05-01 13:24 UTC (permalink / raw)
  To: Andreas Karlsson <andreas@proxel.se>; Bruce Momjian <bruce@momjian.us>; PostgreSQL-development <pgsql-hackers@lists.postgresql.org>

Hi,
I see on many UTF-8 customer bases expression-based index on lower(col) to fulfill some ORM implementation (lower(col) = lower(exp) or "ilike" but ilike is even more "difficult" to index so lower(col) is not so bad...) If pg 19 makes lower(utf-8_text) faster, it's definitely something I would be happy to read in a major upgrade .
Best regards,
Phil

________________________________
De : Andreas Karlsson <andreas@proxel.se>
Envoyé : jeudi 30 avril 2026 09:16
À : Bruce Momjian <bruce@momjian.us>; PostgreSQL-development <pgsql-hackers@lists.postgresql.org>
Objet : Re: First draft of PG 19 release notes

On 4/30/26 9:08 AM, Andreas Karlsson wrote:
> I noticed that two of my performance patches were not included in the
> release notes and I personally think one of them belongs in the release
> notes while other not.
>
> The one I think belongs is the one below since it it really results in
> major speedups of lower(), upper(), initcap() and casefold() on ICU with
> UTF-8. Not having to convert from UTF-8 to UTF-32 and back is often a
> major speedup.

Saw the big discussion on performance improvements if they should be
included or not. So I will just leave this alone. :)

--
Andreas Karlsson
Percona

^ permalink  raw  reply  [nested|flat] 129+ messages in thread

* Re: First draft of PG 19 release notes
@ 2026-05-07 20:20  Bruce Momjian <bruce@momjian.us>
  parent: Bruce Momjian <bruce@momjian.us>
  0 siblings, 0 replies; 129+ messages in thread

From: Bruce Momjian @ 2026-05-07 20:20 UTC (permalink / raw)
  To: David Rowley <dgrowleyml@gmail.com>; +Cc: Andres Freund <andres@anarazel.de>; David Geier <geidav.pg@gmail.com>; PostgreSQL-development <pgsql-hackers@lists.postgresql.org>

On Thu, Apr 23, 2026 at 11:10:03AM -0400, Bruce Momjian wrote:
> On Wed, Apr 22, 2026 at 03:11:23AM -0400, Bruce Momjian wrote:
> > On Tue, Apr 21, 2026 at 05:17:13PM -0400, Bruce Momjian wrote:
> > > On Tue, Apr 21, 2026 at 04:18:40PM -0400, Bruce Momjian wrote:
> > > > Let me work on creating such a list and we will see how it goes.  I am
> > > > traveling now so it will be delayed.
> > > 
> > > That was easy with awk, so done and attached.  There are 1556 commits
> > > from the start of PG 19 to the AS OF date of the release notes that I
> > > did not include in the release notes.
> > 
> > Here is a better version with the "[DOC]" marker I use.
> 
> I documented how I created this "excluded commits" list as item 12 here:
> 
> 	https://wiki.postgresql.org/wiki/Creating_Major_Release_Notes

In item 2, I added a link to my MicroEmacs 4 text editor macros in case
someone needs to port those to another text editor.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Do not let urgent matters crowd out time for investment in the future.





^ permalink  raw  reply  [nested|flat] 129+ messages in thread

* Re: First draft of PG 19 release notes
@ 2026-05-07 22:01  Bruce Momjian <bruce@momjian.us>
  parent: Xuneng Zhou <xunengzhou@gmail.com>
  0 siblings, 0 replies; 129+ messages in thread

From: Bruce Momjian @ 2026-05-07 22:01 UTC (permalink / raw)
  To: Xuneng Zhou <xunengzhou@gmail.com>; +Cc: PostgreSQL-development <pgsql-hackers@lists.postgresql.org>

On Mon, Apr 20, 2026 at 09:03:41PM +0800, Xuneng Zhou wrote:
> Thanks for working on the draft. Here're some comments for it:
> 
> 1) Improve performance of pgstattuple by using streaming reads
> 
> There are two related commits that improve the performance of
> pgstattuple. The current hyperlink references [1]; would it make sense
> to include [2] too?

Sure, added.

> [1] https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=213f0079b
> [2] https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=ae58189a4d523f0156ebe30f4534180555669...
> 
> 
> 2) Additionally, would this[3] be something worth mentioning in the
> General Performance section? The improvement looks fairly big.
> 
> [3] https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=6c228755add8f0714677440d53a160f9ed332...

Sure, I added it to an existing item.

> 3) Allow standbys to wait for LSN values to be replayed via WAIT FOR
> As for this feature, the follow-up commit[4] extends the WAIT FOR
> command to support waiting for flush and write operations. Is it
> helpful for users to be aware of these use cases as well?
> 
> [4] https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=49a181b5d634340fcfb7c762c387c03f64053...

Oh, that's a good point.  I missed that additional functionality.

All fixed in the attached, applied patch.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Do not let urgent matters crowd out time for investment in the future.

Attachments:

  [text/x-diff] master.diff (1.9K, ../../af0LrP9xPkxk5Dpc@momjian.us/2-master.diff)
  download | inline diff:
diff --git a/doc/src/sgml/release-19.sgml b/doc/src/sgml/release-19.sgml
index 6e519a8fdf7..1539f1e56d9 100644
--- a/doc/src/sgml/release-19.sgml
+++ b/doc/src/sgml/release-19.sgml
@@ -756,12 +756,15 @@ Improve performance of internal row deformation (David Rowley)
 <!--
 Author: Michael Paquier <michael@paquier.xyz>
 2026-03-16 [bfa3c4f10] Optimize hash index bulk-deletion with streaming read
+Author: Michael Paquier <michael@paquier.xyz>
+2026-03-12 [6c228755a] Use streaming read for VACUUM cleanup of GIN
 -->
 
 <listitem>
 <para>
-Improve performance of hash index bulk-deletion by using streaming reads (Xuneng Zhou)
+Improve performance of hash index bulk-deletion and GIN index vacuuming using streaming reads (Xuneng Zhou)
 <ulink url="&commit_baseurl;bfa3c4f10">&sect;</ulink>
+<ulink url="&commit_baseurl;6c228755a">&sect;</ulink>
 </para>
 </listitem>
 
@@ -1340,7 +1343,7 @@ Author: Alexander Korotkov <akorotkov@postgresql.org>
 
 <listitem>
 <para>
-Allow standbys to wait for LSN values to be replayed via WAIT FOR (Kartyshov Ivan, Alexander Korotkov, Xuneng Zhou)
+Allow standbys to wait for LSN values to be written, flushed, or replayed via WAIT FOR (Kartyshov Ivan, Alexander Korotkov, Xuneng Zhou)
 <ulink url="&commit_baseurl;447aae13b">&sect;</ulink>
 <ulink url="&commit_baseurl;49a181b5d">&sect;</ulink>
 </para>
@@ -3332,12 +3335,15 @@ Improve performance of bloom indexes by using streaming reads (Xuneng Zhou)
 <!--
 Author: Michael Paquier <michael@paquier.xyz>
 2026-03-13 [213f0079b] pgstattuple: Optimize btree and hash index functions wit
+Author: Michael Paquier <michael@paquier.xyz>
+2026-03-14 [ae58189a4] pgstattuple: Optimize pgstattuple_approx() with streamin
 -->
 
 <listitem>
 <para>
 Improve performance of pgstattuple by using streaming reads (Xuneng Zhou)
 <ulink url="&commit_baseurl;213f0079b">&sect;</ulink>
+<ulink url="&commit_baseurl;ae58189a4">&sect;</ulink>
 </para>
 </listitem>
 

^ permalink  raw  reply  [nested|flat] 129+ messages in thread

* Re: First draft of PG 19 release notes
@ 2026-05-07 23:08  Bruce Momjian <bruce@momjian.us>
  parent: Etsuro Fujita <etsuro.fujita@gmail.com>
  0 siblings, 1 reply; 129+ messages in thread

From: Bruce Momjian @ 2026-05-07 23:08 UTC (permalink / raw)
  To: Etsuro Fujita <etsuro.fujita@gmail.com>; +Cc: PostgreSQL-development <pgsql-hackers@lists.postgresql.org>

On Tue, Apr 21, 2026 at 05:24:59AM -0700, Etsuro Fujita wrote:
> On Wed, Apr 15, 2026 at 10:19 AM Bruce Momjian <bruce@momjian.us> wrote:
> > I have completed the first draft of the PG 19 release notes:
> >
> >         https://www.postgresql.org/docs/devel/release-19.html
> 
> Thank you!
> 
> "Allow the retrieval of statistics from foreign data wrapper servers
> (Corey Huinker, Etsuro Fujita)"
> 
> This is mentioned in the Additional Modules section, presumably
> because it was supported in postgres_fdw, but it isn't limited to
> postgres_fdw, so we should move it to the General Performance section?

Well, the full text is:

	Allow the retrieval of statistics from foreign data wrapper servers
	(Corey Huinker, Etsuro Fujita) §
	
	This is enabled for postgres_fdw by using the option restore_stats. The
	default is for ANALYZE to retrieve rows from the remote server to
	locally generate statistics.

It clearly mentions in the detail that it applies only to postgres_fdw,
so I think it is already in the right section.  While it technically can
be done by any FDW, it is now only postgres_fdw so people looking for
postgres_fdw improvements will find it in the Additional Modules
section.  What we can do is to reword it to:

-->	Allow the retrieval of statistics from postgres_fdw foreign data wrapper servers
	(Corey Huinker, Etsuro Fujita) §
	
-->	This is enabled by using the option restore_stats. The
	default is for ANALYZE to retrieve rows from the remote server to
	locally generate statistics.

but I think this is worse because it sounds like it can _only_ ever be
done by postgres_fdw.  However, if you prefer this I will make this
change.

I avoided "General Performance" because frankly, it is only
postgres_fdw, and it not a "General" performance improvement, and we
have a section for postgres_fdw already.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Do not let urgent matters crowd out time for investment in the future.





^ permalink  raw  reply  [nested|flat] 129+ messages in thread

* Re: First draft of PG 19 release notes
@ 2026-05-08 00:20  Bruce Momjian <bruce@momjian.us>
  parent: jian he <jian.universality@gmail.com>
  0 siblings, 0 replies; 129+ messages in thread

From: Bruce Momjian @ 2026-05-08 00:20 UTC (permalink / raw)
  To: jian he <jian.universality@gmail.com>; +Cc: PostgreSQL-development <pgsql-hackers@lists.postgresql.org>

On Wed, Apr 22, 2026 at 11:10:06AM +0800, jian he wrote:
> On Wed, Apr 15, 2026 at 9:19 AM Bruce Momjian <bruce@momjian.us> wrote:
> >
> > I have completed the first draft of the PG 19 release notes:
> >
> >         https://www.postgresql.org/docs/devel/release-19.html
> >
> 
> Change FDW function prototypes to use uint* instead of bit* typedefs
> (Nathan Bossart) §
> This commit doesn't seem related to FDW?

Wow, I have no idea why I put FDW in there.  Next text is:

	Change function prototypes to use uint* instead of bit* typedefs (Nathan
	Bossart)

> Allow btree_gin to match partial qualifications (Tom Lane) § §
> I don't understand "partial qualifications", the commit seems more
> about "cross type operators".

Yeah, another mistake.  I got the description from this doc change in
the patch:

+       Compare a partial-match query key to an index key.
+       <literal>partial_key</literal> is a query key that was returned
+       by <function>extractQuery</function> with an indication that it
+       requires partial match, and <literal>key</literal> is an index entry.
+       Returns an integer

but that is only a clarification of an existing sentence, and I mistook
that for a new feature.  If a patch has a doc change, I tend to focus on
that, but made a mistake here.  New text is:

	Change btree_gin to support all btree-supported cross-type comparisons
	(Tom Lane)

> https://git.postgresql.org/cgit/postgresql.git/commit/?id=999f172d
> Can this also be added to the release notes?

Uh, I saw that one, and I don't normally mention changes where rare
actions used to generate errors, and don't anymore, and I saw this one
as being in that category.

> Do you think this
> (https://git.postgresql.org/cgit/postgresql.git/commit/?id=00c025a001170979e99706ce746f75fcc615761d)
> worth add to the release notes?
>
> Before commit:
> https://www.postgresql.org/docs/current/functions-matching.html#FUNCTIONS-POSIX-REGEXP
> After commit:
> https://www.postgresql.org/docs/devel/functions-matching.html#FUNCTIONS-POSIX-LIST

I saw this as a documentation restructuring, and I usually only mention
document changes that create significant new content.

Attached patch applied.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Do not let urgent matters crowd out time for investment in the future.

Attachments:

  [text/x-diff] master.diff (861B, ../../af0sSOqcDhDJk_Os@momjian.us/2-master.diff)
  download | inline diff:
diff --git a/doc/src/sgml/release-19.sgml b/doc/src/sgml/release-19.sgml
index 1539f1e56d9..008405623e1 100644
--- a/doc/src/sgml/release-19.sgml
+++ b/doc/src/sgml/release-19.sgml
@@ -3086,7 +3086,7 @@ Author: Nathan Bossart <nathan@postgresql.org>
 
 <listitem>
 <para>
-Change FDW function prototypes to use uint* instead of bit* typedefs (Nathan Bossart)
+Change function prototypes to use uint* instead of bit* typedefs (Nathan Bossart)
 <ulink url="&commit_baseurl;bab2f27ea">&sect;</ulink>
 </para>
 </listitem>
@@ -3311,7 +3311,7 @@ Author: Tom Lane <tgl@sss.pgh.pa.us>
 
 <listitem>
 <para>
-Allow btree_gin to match partial qualifications (Tom Lane)
+Change btree_gin to support all btree-supported cross-type comparisons (Tom Lane)
 <ulink url="&commit_baseurl;e2b64fcef">&sect;</ulink>
 <ulink url="&commit_baseurl;fc896821c">&sect;</ulink>
 </para>

^ permalink  raw  reply  [nested|flat] 129+ messages in thread

* Re: First draft of PG 19 release notes
@ 2026-05-08 00:52  Bruce Momjian <bruce@momjian.us>
  parent: Phil Florent <philflorent@hotmail.com>
  0 siblings, 0 replies; 129+ messages in thread

From: Bruce Momjian @ 2026-05-08 00:52 UTC (permalink / raw)
  To: Phil Florent <philflorent@hotmail.com>; +Cc: Andreas Karlsson <andreas@proxel.se>; PostgreSQL-development <pgsql-hackers@lists.postgresql.org>

On Fri, May  1, 2026 at 01:24:51PM +0000, Phil Florent wrote:
> Hi,
> I see on many UTF-8 customer bases expression-based index on lower(col) to
> fulfill some ORM implementation (lower(col) = lower(exp) or "ilike" but ilike
> is even more "difficult" to index so lower(col) is not so bad...) If pg 19
> makes lower(utf-8_text) faster, it's definitely something I would be happy to
> read in a major upgrade . 

Yes, agreed.  I had not considered how impactful this would be, based on
the commit message.  Index usage sounds like a huge win.  Attached patch
applied.

---------------------------------------------------------------------------


> Best regards,
> Phil
> 
> ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
> De : Andreas Karlsson <andreas@proxel.se>
> Envoyé : jeudi 30 avril 2026 09:16
> À : Bruce Momjian <bruce@momjian.us>; PostgreSQL-development
> <pgsql-hackers@lists.postgresql.org>
> Objet : Re: First draft of PG 19 release notes
>  
> On 4/30/26 9:08 AM, Andreas Karlsson wrote:
> > I noticed that two of my performance patches were not included in the
> > release notes and I personally think one of them belongs in the release
> > notes while other not.
> >
> > The one I think belongs is the one below since it it really results in
> > major speedups of lower(), upper(), initcap() and casefold() on ICU with
> > UTF-8. Not having to convert from UTF-8 to UTF-32 and back is often a
> > major speedup.
> 
> Saw the big discussion on performance improvements if they should be
> included or not. So I will just leave this alone. :)
> 
> --
> Andreas Karlsson
> Percona
> 
> 
> 

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Do not let urgent matters crowd out time for investment in the future.

Attachments:

  [text/x-diff] master.diff (725B, ../../af0z0ywC9CZ2It31@momjian.us/2-master.diff)
  download | inline diff:
diff --git a/doc/src/sgml/release-19.sgml b/doc/src/sgml/release-19.sgml
index 008405623e1..f265ac00eb2 100644
--- a/doc/src/sgml/release-19.sgml
+++ b/doc/src/sgml/release-19.sgml
@@ -753,6 +753,18 @@ Improve performance of internal row deformation (David Rowley)
 </para>
 </listitem>
 
+<!--
+Author: Jeff Davis <jdavis@postgresql.org>
+2026-01-06 [c4ff35f10] ICU: use UTF8-optimized case conversion API
+-->
+
+<listitem>
+<para>
+Improve performance of repeated UTF-8 case-folding operations (Andreas Karlsson)
+<ulink url="&commit_baseurl;c4ff35f10">&sect;</ulink>
+</para>
+</listitem>
+
 <!--
 Author: Michael Paquier <michael@paquier.xyz>
 2026-03-16 [bfa3c4f10] Optimize hash index bulk-deletion with streaming read

^ permalink  raw  reply  [nested|flat] 129+ messages in thread

* Re: First draft of PG 19 release notes
@ 2026-05-08 00:54  Bruce Momjian <bruce@momjian.us>
  parent: Richard Guo <guofenglinux@gmail.com>
  0 siblings, 1 reply; 129+ messages in thread

From: Bruce Momjian @ 2026-05-08 00:54 UTC (permalink / raw)
  To: Richard Guo <guofenglinux@gmail.com>; +Cc: PostgreSQL-development <pgsql-hackers@lists.postgresql.org>

On Fri, May  1, 2026 at 10:16:24AM +0900, Richard Guo wrote:
> On Wed, Apr 15, 2026 at 10:19 AM Bruce Momjian <bruce@momjian.us> wrote:
> > I have completed the first draft of the PG 19 release notes:
> >
> >         https://www.postgresql.org/docs/devel/release-19.html
> 
> I just committed 8d829f5a0 to fix JSON_ARRAY(subquery) to return an
> empty JSON array instead of NULL over an empty result set, per the
> SQL/JSON standard.  Since this is a user-visible behavior change, we
> need to add an item to the v19 migration section to call it out.
> 
> Suggested entry:
> 
>  - Make JSON_ARRAY(query_expression) return an empty JSON array when
>    the subquery returns no rows (Richard Guo)
> 
>    Previously, an empty result set produced NULL.  This corrects the
>    behavior to match the SQL/JSON standard.  Application code that
>    relied on the previous NULL behavior may need to be updated.

I will add this as soon as I update with the new commits.  Thanks.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Do not let urgent matters crowd out time for investment in the future.





^ permalink  raw  reply  [nested|flat] 129+ messages in thread

* Re: First draft of PG 19 release notes
@ 2026-05-09 09:15  Etsuro Fujita <etsuro.fujita@gmail.com>
  parent: Bruce Momjian <bruce@momjian.us>
  0 siblings, 1 reply; 129+ messages in thread

From: Etsuro Fujita @ 2026-05-09 09:15 UTC (permalink / raw)
  To: Bruce Momjian <bruce@momjian.us>; +Cc: PostgreSQL-development <pgsql-hackers@lists.postgresql.org>

On Fri, May 8, 2026 at 8:08 AM Bruce Momjian <bruce@momjian.us> wrote:
> On Tue, Apr 21, 2026 at 05:24:59AM -0700, Etsuro Fujita wrote:
> > "Allow the retrieval of statistics from foreign data wrapper servers
> > (Corey Huinker, Etsuro Fujita)"
> >
> > This is mentioned in the Additional Modules section, presumably
> > because it was supported in postgres_fdw, but it isn't limited to
> > postgres_fdw, so we should move it to the General Performance section?
>
> Well, the full text is:
>
>         Allow the retrieval of statistics from foreign data wrapper servers
>         (Corey Huinker, Etsuro Fujita) §
>
>         This is enabled for postgres_fdw by using the option restore_stats. The
>         default is for ANALYZE to retrieve rows from the remote server to
>         locally generate statistics.
>
> It clearly mentions in the detail that it applies only to postgres_fdw,
> so I think it is already in the right section.  While it technically can
> be done by any FDW, it is now only postgres_fdw so people looking for
> postgres_fdw improvements will find it in the Additional Modules
> section.  What we can do is to reword it to:
>
> -->     Allow the retrieval of statistics from postgres_fdw foreign data wrapper servers
>         (Corey Huinker, Etsuro Fujita) §
>
> -->     This is enabled by using the option restore_stats. The
>         default is for ANALYZE to retrieve rows from the remote server to
>         locally generate statistics.
>
> but I think this is worse because it sounds like it can _only_ ever be
> done by postgres_fdw.  However, if you prefer this I will make this
> change.
>
> I avoided "General Performance" because frankly, it is only
> postgres_fdw, and it not a "General" performance improvement, and we
> have a section for postgres_fdw already.

Agreed.  I think the current text is fine.

Thank you for your detailed reply!

Best regards,
Etsuro Fujita





^ permalink  raw  reply  [nested|flat] 129+ messages in thread

* Re: First draft of PG 19 release notes
@ 2026-05-11 05:40  John Naylor <johncnaylorls@gmail.com>
  parent: Bruce Momjian <bruce@momjian.us>
  0 siblings, 1 reply; 129+ messages in thread

From: John Naylor @ 2026-05-11 05:40 UTC (permalink / raw)
  To: Bruce Momjian <bruce@momjian.us>; +Cc: Richard Guo <guofenglinux@gmail.com>; PostgreSQL-development <pgsql-hackers@lists.postgresql.org>

On Wed, Apr 15, 2026 at 8:19 AM Bruce Momjian <bruce@momjian.us> wrote:

Hi Bruce, thanks for you work on this. Here are some comments:

> Allow C++ compiler mode to be used with ICU (John Naylor) §

That was just for our headerscheck and I'd be surprised if it mattered
for extension authors. Also, a later commit af2d4ca191 got rid of
including ICU headers in our local headers entirely, so that
supercedes the above anyway.

> Optionally use AVX2 CPU instructions for calculating page checksums (Matthew Sterrett, Andrew Kim) §

> Optionally use ARM Crypto Extension to Compute CRC32C (John Naylor) §

There's no option for these, the extensions are used where available.

> Improve sort performance using radix sorts (John Naylor) §

Minor quibble: I think it's more normal to refer to "sort" as a
non-count noun, when talking about a technique.

> Improve performance of numeric operations on platforms without 128-bit integer support (Dean Rasheed) §

The intent was a more of a simplification/refactoring. Server
platforms without 128-bit integer support are few and far between
(e.g. S390X on some broken versions of clang, which I tested out of
curiosity).

> Change index access method handlers to use a static IndexAmRoutines structure, rather than dynamically allocated ones (Matthias van de Meent) §
>
> This is a backwardly incompatible.

I understand this whole section to be about incompatibilities -- if
there was a follow-up mention here, it seems to have been lost along
the way.

--
John Naylor
Amazon Web Services

-- 
John Naylor
Amazon Web Services





^ permalink  raw  reply  [nested|flat] 129+ messages in thread

* Re: First draft of PG 19 release notes
@ 2026-05-11 21:42  Bruce Momjian <bruce@momjian.us>
  parent: John Naylor <johncnaylorls@gmail.com>
  0 siblings, 1 reply; 129+ messages in thread

From: Bruce Momjian @ 2026-05-11 21:42 UTC (permalink / raw)
  To: John Naylor <johncnaylorls@gmail.com>; +Cc: Richard Guo <guofenglinux@gmail.com>; PostgreSQL-development <pgsql-hackers@lists.postgresql.org>

On Mon, May 11, 2026 at 12:40:38PM +0700, John Naylor wrote:
> On Wed, Apr 15, 2026 at 8:19 AM Bruce Momjian <bruce@momjian.us> wrote:
> 
> Hi Bruce, thanks for you work on this. Here are some comments:
> 
> > Allow C++ compiler mode to be used with ICU (John Naylor) §
> 
> That was just for our headerscheck and I'd be surprised if it mattered
> for extension authors. Also, a later commit af2d4ca191 got rid of
> including ICU headers in our local headers entirely, so that
> supersedes the above anyway.

Great, removed.

> > Optionally use AVX2 CPU instructions for calculating page checksums (Matthew Sterrett, Andrew Kim) §
> 
> > Optionally use ARM Crypto Extension to Compute CRC32C (John Naylor) §
> 
> There's no option for these, the extensions are used where available.

So, the "Optionally" indicates we use these instructions if the CPU
supports them.  I assume we don't use them on all CPUs.  Can you
suggest better wording?

> > Improve sort performance using radix sorts (John Naylor) §
> 
> Minor quibble: I think it's more normal to refer to "sort" as a
> non-count noun, when talking about a technique.

Done.

> > Improve performance of numeric operations on platforms without 128-bit integer support (Dean Rasheed) §
> 
> The intent was a more of a simplification/refactoring. Server
> platforms without 128-bit integer support are few and far between
> (e.g. S390X on some broken versions of clang, which I tested out of
> curiosity).

Okay, removed.

> > Change index access method handlers to use a static IndexAmRoutines structure, rather than dynamically allocated ones (Matthias van de Meent) §
> >
> > This is a backwardly incompatible.
> 
> I understand this whole section to be about incompatibilities -- if
> there was a follow-up mention here, it seems to have been lost along
> the way.

Okay, I have removed "This is a backwardly incompatible.", which I think
was your point.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Do not let urgent matters crowd out time for investment in the future.





^ permalink  raw  reply  [nested|flat] 129+ messages in thread

* Re: First draft of PG 19 release notes
@ 2026-05-12 02:34  Robert Treat <rob@xzilla.net>
  parent: Bruce Momjian <bruce@momjian.us>
  0 siblings, 1 reply; 129+ messages in thread

From: Robert Treat @ 2026-05-12 02:34 UTC (permalink / raw)
  To: Bruce Momjian <bruce@momjian.us>; +Cc: John Naylor <johncnaylorls@gmail.com>; Richard Guo <guofenglinux@gmail.com>; PostgreSQL-development <pgsql-hackers@lists.postgresql.org>

On Mon, May 11, 2026 at 5:42 PM Bruce Momjian <bruce@momjian.us> wrote:
> On Mon, May 11, 2026 at 12:40:38PM +0700, John Naylor wrote:
> > On Wed, Apr 15, 2026 at 8:19 AM Bruce Momjian <bruce@momjian.us> wrote:
> >
> > Hi Bruce, thanks for you work on this. Here are some comments:
> >
<snip>
> > > Optionally use AVX2 CPU instructions for calculating page checksums (Matthew Sterrett, Andrew Kim) §
> >
> > > Optionally use ARM Crypto Extension to Compute CRC32C (John Naylor) §
> >
> > There's no option for these, the extensions are used where available.
>
> So, the "Optionally" indicates we use these instructions if the CPU
> supports them.  I assume we don't use them on all CPUs.  Can you
> suggest better wording?
>

I think the simplest change would be to replace "optionally" with
"when available", although ISTR we use wording along the lines of "Add
support for" or "is now supported" when runtime/compiler checks are
involved.

Robert Treat
https://xzilla.net





^ permalink  raw  reply  [nested|flat] 129+ messages in thread

* Re: First draft of PG 19 release notes
@ 2026-05-12 03:38  John Naylor <johncnaylorls@gmail.com>
  parent: Robert Treat <rob@xzilla.net>
  0 siblings, 1 reply; 129+ messages in thread

From: John Naylor @ 2026-05-12 03:38 UTC (permalink / raw)
  To: Robert Treat <rob@xzilla.net>; +Cc: Bruce Momjian <bruce@momjian.us>; PostgreSQL-development <pgsql-hackers@lists.postgresql.org>

On Tue, May 12, 2026 at 9:35 AM Robert Treat <rob@xzilla.net> wrote:
>
> On Mon, May 11, 2026 at 5:42 PM Bruce Momjian <bruce@momjian.us> wrote:
> > On Mon, May 11, 2026 at 12:40:38PM +0700, John Naylor wrote:
> > > > Optionally use AVX2 CPU instructions for calculating page checksums (Matthew Sterrett, Andrew Kim) §
> > >
> > > > Optionally use ARM Crypto Extension to Compute CRC32C (John Naylor) §
> > >
> > > There's no option for these, the extensions are used where available.
> >
> > So, the "Optionally" indicates we use these instructions if the CPU
> > supports them.  I assume we don't use them on all CPUs.  Can you
> > suggest better wording?
> >
>
> I think the simplest change would be to replace "optionally" with
> "when available", although ISTR we use wording along the lines of "Add
> support for" or "is now supported" when runtime/compiler checks are
> involved.

That would be fine. The v17 and v18 release notes didn't have such
qualifying language, for things that are less common than the above
(SVE, AVX-512), but whatever.

-- 
John Naylor
Amazon Web Services





^ permalink  raw  reply  [nested|flat] 129+ messages in thread

* Re: First draft of PG 19 release notes
@ 2026-05-12 04:11  jian he <jian.universality@gmail.com>
  parent: Bruce Momjian <bruce@momjian.us>
  25 siblings, 1 reply; 129+ messages in thread

From: jian he @ 2026-05-12 04:11 UTC (permalink / raw)
  To: Bruce Momjian <bruce@momjian.us>; +Cc: PostgreSQL-development <pgsql-hackers@lists.postgresql.org>

On Wed, Apr 15, 2026 at 9:19 AM Bruce Momjian <bruce@momjian.us> wrote:
>
> I have completed the first draft of the PG 19 release notes:
>
>         https://www.postgresql.org/docs/devel/release-19.html
>

Add hooks planner_setup_hook and planner_shutdown_hook (Robert Haas) §

https://git.postgresql.org/cgit/postgresql.git/commit/?id=4020b37
We also introduced join_path_setup_hook, joinrel_setup_hook.

Should we also mention these two hooks?





^ permalink  raw  reply  [nested|flat] 129+ messages in thread

* Re: First draft of PG 19 release notes
@ 2026-05-12 12:41  Greg Sabino Mullane <htamfids@gmail.com>
  parent: Bruce Momjian <bruce@momjian.us>
  25 siblings, 2 replies; 129+ messages in thread

From: Greg Sabino Mullane @ 2026-05-12 12:41 UTC (permalink / raw)
  To: Bruce Momjian <bruce@momjian.us>; +Cc: PostgreSQL-development <pgsql-hackers@lists.postgresql.org>; David Christensen <david+pg@pgguru.net>

I can kind of understand why this did not make the cut:

https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=41d69e6d

(Add labels to help make psql's hidden queries more understandable)

... but I'm in favor (yes, somewhat selfishly to be honest) of listing all
changes, no matter how small. Is there a written criteria or guidelines for
these things? I think the bar is already low if we list things like
"improved tab completion", TBH.

^ permalink  raw  reply  [nested|flat] 129+ messages in thread

* Re: First draft of PG 19 release notes
@ 2026-05-12 14:57  Melanie Plageman <melanieplageman@gmail.com>
  parent: Greg Sabino Mullane <htamfids@gmail.com>
  1 sibling, 1 reply; 129+ messages in thread

From: Melanie Plageman @ 2026-05-12 14:57 UTC (permalink / raw)
  To: Greg Sabino Mullane <htamfids@gmail.com>; +Cc: Bruce Momjian <bruce@momjian.us>; PostgreSQL-development <pgsql-hackers@lists.postgresql.org>; David Christensen <david+pg@pgguru.net>

On Tue, May 12, 2026 at 8:42 AM Greg Sabino Mullane <htamfids@gmail.com> wrote:
>
> I can kind of understand why this did not make the cut:
>
> https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=41d69e6d
>
> (Add labels to help make psql's hidden queries more understandable)
>
> ... but I'm in favor (yes, somewhat selfishly to be honest) of listing all changes, no matter how small. Is there a written criteria or guidelines for these things? I think the bar is already low if we list things like "improved tab completion", TBH.

I agree that it is hard to know when advocating for our own features
makes sense on this thread. When another feature makes the list that
seems to have a less compelling case, it is tempting to jump in again.
But then, how do we know we are being objective and doing what is in
the best interest of the user reading the release notes?

For example, I upthread [1] suggested that users may want to know that
different WAL records would be produced because we've eliminated one
and incorporated their contents into another. While it is a
performance improvement, I mainly suggested it because an advanced
user examining WAL may be confused. Bruce noted that this was too
internal. I can see his point. But there are other things mentioned
that are as internal or more so. But arguing makes me feel like I'm
doing self-promotion. I've transitioned to only bringing up things
that I did that seem like they would be confusing to the user and they
would go to the release notes to check for, as opposed to bringing up
performance improvements.

However, for performance improvements, at some point the bar was
something that would encourage people to go through the effort of
upgrading to the latest version to get those improvements or to
migrate to Postgres when they previously may not have because a
performance related thing was holding them back. Things like improved
tab completion are probably not this kind of tipping point, so I think
that isn't the threshold anymore.

I would be interested in seeing a summary of where we landed in terms
of criteria for what should be in the release notes on this thread,
since it is split across many emails. I get the sense that we've
shifted it a bit based on discussion in this thread, and I can't quite
grasp the specifics. And people who replied early on but not after the
discussion led to changes may not be paying attention to the thread
anymore.

- Melanie

[1] https://www.postgresql.org/message-id/ad_6RBwUlRooQK-9%40momjian.us





^ permalink  raw  reply  [nested|flat] 129+ messages in thread

* Re: First draft of PG 19 release notes
@ 2026-05-12 19:11  Bruce Momjian <bruce@momjian.us>
  parent: John Naylor <johncnaylorls@gmail.com>
  0 siblings, 0 replies; 129+ messages in thread

From: Bruce Momjian @ 2026-05-12 19:11 UTC (permalink / raw)
  To: John Naylor <johncnaylorls@gmail.com>; +Cc: Robert Treat <rob@xzilla.net>; PostgreSQL-development <pgsql-hackers@lists.postgresql.org>

On Tue, May 12, 2026 at 10:38:40AM +0700, John Naylor wrote:
> On Tue, May 12, 2026 at 9:35 AM Robert Treat <rob@xzilla.net> wrote:
> >
> > On Mon, May 11, 2026 at 5:42 PM Bruce Momjian <bruce@momjian.us> wrote:
> > > On Mon, May 11, 2026 at 12:40:38PM +0700, John Naylor wrote:
> > > > > Optionally use AVX2 CPU instructions for calculating page checksums (Matthew Sterrett, Andrew Kim) §
> > > >
> > > > > Optionally use ARM Crypto Extension to Compute CRC32C (John Naylor) §
> > > >
> > > > There's no option for these, the extensions are used where available.
> > >
> > > So, the "Optionally" indicates we use these instructions if the CPU
> > > supports them.  I assume we don't use them on all CPUs.  Can you
> > > suggest better wording?
> > >
> >
> > I think the simplest change would be to replace "optionally" with
> > "when available", although ISTR we use wording along the lines of "Add
> > support for" or "is now supported" when runtime/compiler checks are
> > involved.
> 
> That would be fine. The v17 and v18 release notes didn't have such
> qualifying language, for things that are less common than the above
> (SVE, AVX-512), but whatever.

Okay, I will just remove the "Optionally" and see if anyone complains.
Patch attached and applied.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Do not let urgent matters crowd out time for investment in the future.

Attachments:

  [text/x-diff] master.diff (836B, ../../agN7VMAqao8_v-4v@momjian.us/2-master.diff)
  download | inline diff:
diff --git a/doc/src/sgml/release-19.sgml b/doc/src/sgml/release-19.sgml
index 96f6c4377c9..b21549c1de5 100644
--- a/doc/src/sgml/release-19.sgml
+++ b/doc/src/sgml/release-19.sgml
@@ -2950,7 +2950,7 @@ Author: John Naylor <john.naylor@postgresql.org>
 
 <listitem>
 <para>
-Optionally use AVX2 CPU instructions for calculating page checksums (Matthew Sterrett, Andrew Kim)
+Use AVX2 CPU instructions for calculating page checksums (Matthew Sterrett, Andrew Kim)
 <ulink url="&commit_baseurl;5e13b0f24">&sect;</ulink>
 </para>
 </listitem>
@@ -2962,7 +2962,7 @@ Author: John Naylor <john.naylor@postgresql.org>
 
 <listitem>
 <para>
-Optionally use ARM Crypto Extension to Compute CRC32C (John Naylor)
+Use ARM Crypto Extension to Compute CRC32C (John Naylor)
 <ulink url="&commit_baseurl;fbc57f2bc">&sect;</ulink>
 </para>
 </listitem>

^ permalink  raw  reply  [nested|flat] 129+ messages in thread

* Re: First draft of PG 19 release notes
@ 2026-05-12 20:15  Bruce Momjian <bruce@momjian.us>
  parent: jian he <jian.universality@gmail.com>
  0 siblings, 0 replies; 129+ messages in thread

From: Bruce Momjian @ 2026-05-12 20:15 UTC (permalink / raw)
  To: jian he <jian.universality@gmail.com>; +Cc: PostgreSQL-development <pgsql-hackers@lists.postgresql.org>

On Tue, May 12, 2026 at 12:11:16PM +0800, jian he wrote:
> On Wed, Apr 15, 2026 at 9:19 AM Bruce Momjian <bruce@momjian.us> wrote:
> >
> > I have completed the first draft of the PG 19 release notes:
> >
> >         https://www.postgresql.org/docs/devel/release-19.html
> >
> 
> Add hooks planner_setup_hook and planner_shutdown_hook (Robert Haas) §
> 
> https://git.postgresql.org/cgit/postgresql.git/commit/?id=4020b37
> We also introduced join_path_setup_hook, joinrel_setup_hook.
> 
> Should we also mention these two hooks?

Yes, I missed seeing the addition of these two hooks, so patch attached
and applied.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Do not let urgent matters crowd out time for investment in the future.

Attachments:

  [text/x-diff] master.diff (854B, ../../agOKWlyZtHJkG_Cs@momjian.us/2-master.diff)
  download | inline diff:
diff --git a/doc/src/sgml/release-19.sgml b/doc/src/sgml/release-19.sgml
index b21549c1de5..ff66009e046 100644
--- a/doc/src/sgml/release-19.sgml
+++ b/doc/src/sgml/release-19.sgml
@@ -3018,12 +3018,15 @@ Update Unicode data to version 17.0.0 (Peter Eisentraut)
 <!--
 Author: Robert Haas <rhaas@postgresql.org>
 2025-10-08 [94f3ad396] Add planner_setup_hook and planner_shutdown_hook.
+Author: Robert Haas <rhaas@postgresql.org>
+2026-01-28 [4020b370f] Allow for plugin control over path generation strategies
 -->
 
 <listitem>
 <para>
-Add hooks planner_setup_hook and planner_shutdown_hook (Robert Haas)
+Add hooks planner_setup_hook, planner_shutdown_hook, joinrel_setup_hook, and join_path_setup_hook (Robert Haas)
 <ulink url="&commit_baseurl;94f3ad396">&sect;</ulink>
+<ulink url="&commit_baseurl;4020b370f">&sect;</ulink>
 </para>
 </listitem>
 

^ permalink  raw  reply  [nested|flat] 129+ messages in thread

* Re: First draft of PG 19 release notes
@ 2026-05-12 20:27  Bruce Momjian <bruce@momjian.us>
  parent: Greg Sabino Mullane <htamfids@gmail.com>
  1 sibling, 0 replies; 129+ messages in thread

From: Bruce Momjian @ 2026-05-12 20:27 UTC (permalink / raw)
  To: Greg Sabino Mullane <htamfids@gmail.com>; +Cc: PostgreSQL-development <pgsql-hackers@lists.postgresql.org>; David Christensen <david+pg@pgguru.net>

On Tue, May 12, 2026 at 08:41:28AM -0400, Greg Sabino Mullane wrote:
> I can kind of understand why this did not make the cut:
> 
> https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=41d69e6d
> 
> (Add labels to help make psql's hidden queries more understandable)
> 
> ... but I'm in favor (yes, somewhat selfishly to be honest) of listing all
> changes, no matter how small. Is there a written criteria or guidelines for
> these things? I think the bar is already low if we list things like "improved
> tab completion", TBH.

I am not sure how to answer this except to say that I try to list items
that are important for the general reading audience to know.  All
changes are already in the git commit log.

If you would like to make the case that listing all changes would be
helpful for the general reading audience, please make that case.  If you
would like to make the case that being most helpful for the general
reading audience is not the right goal, please explain.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Do not let urgent matters crowd out time for investment in the future.





^ permalink  raw  reply  [nested|flat] 129+ messages in thread

* Re: First draft of PG 19 release notes
@ 2026-05-12 20:31  Bruce Momjian <bruce@momjian.us>
  parent: Melanie Plageman <melanieplageman@gmail.com>
  0 siblings, 0 replies; 129+ messages in thread

From: Bruce Momjian @ 2026-05-12 20:31 UTC (permalink / raw)
  To: Melanie Plageman <melanieplageman@gmail.com>; +Cc: Greg Sabino Mullane <htamfids@gmail.com>; PostgreSQL-development <pgsql-hackers@lists.postgresql.org>; David Christensen <david+pg@pgguru.net>

On Tue, May 12, 2026 at 10:57:57AM -0400, Melanie Plageman wrote:
> I would be interested in seeing a summary of where we landed in terms
> of criteria for what should be in the release notes on this thread,
> since it is split across many emails. I get the sense that we've
> shifted it a bit based on discussion in this thread, and I can't quite
> grasp the specifics. And people who replied early on but not after the
> discussion led to changes may not be paying attention to the thread
> anymore.

If multiple people suggest a change, it is probably the right thing to
do so I do it.  I have posted a list of everything I excluded, so that
could be used to analyze what was missing.  I do miscategorize items
every time I do this, so I expect such adjustments.  If the general
readers report that something is missing or wrong, it means I made a
serious mistake and none of this review process caught it --- it has
happened a few times over the years.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Do not let urgent matters crowd out time for investment in the future.





^ permalink  raw  reply  [nested|flat] 129+ messages in thread

* Re: First draft of PG 19 release notes
@ 2026-05-15 16:31  Peter Geoghegan <pg@bowt.ie>
  parent: Bruce Momjian <bruce@momjian.us>
  25 siblings, 1 reply; 129+ messages in thread

From: Peter Geoghegan @ 2026-05-15 16:31 UTC (permalink / raw)
  To: Bruce Momjian <bruce@momjian.us>; +Cc: PostgreSQL-development <pgsql-hackers@lists.postgresql.org>

On Tue, Apr 14, 2026 at 9:19 PM Bruce Momjian <bruce@momjian.us> wrote:
> I have completed the first draft of the PG 19 release notes:
>
>         https://www.postgresql.org/docs/devel/release-19.html

I do not think that this item merits mention in the release notes:

"Add fake LSN support to hash index AM (Peter Geoghegan)"

It offers no user-visible benefit. It's just preparation for index
prefetching, which didn't make it into Postgres 19.

-- 
Peter Geoghegan





^ permalink  raw  reply  [nested|flat] 129+ messages in thread

* Re: First draft of PG 19 release notes
@ 2026-05-15 17:27  Bruce Momjian <bruce@momjian.us>
  parent: Peter Geoghegan <pg@bowt.ie>
  0 siblings, 1 reply; 129+ messages in thread

From: Bruce Momjian @ 2026-05-15 17:27 UTC (permalink / raw)
  To: Peter Geoghegan <pg@bowt.ie>; +Cc: PostgreSQL-development <pgsql-hackers@lists.postgresql.org>

On Fri, May 15, 2026 at 12:31:59PM -0400, Peter Geoghegan wrote:
> On Tue, Apr 14, 2026 at 9:19 PM Bruce Momjian <bruce@momjian.us> wrote:
> > I have completed the first draft of the PG 19 release notes:
> >
> >         https://www.postgresql.org/docs/devel/release-19.html
> 
> I do not think that this item merits mention in the release notes:
> 
> "Add fake LSN support to hash index AM (Peter Geoghegan)"
> 
> It offers no user-visible benefit. It's just preparation for index
> prefetching, which didn't make it into Postgres 19.

Ah, I see your point, and the commit message was clear:

    This commit is similar to commit 8a879119, which taught nbtree to
    use fake LSNs to improve its dropPin behavior.  However, unlike that
    commit, this is not an independently useful enhancement, since hash
    doesn't implement anything like nbtree's dropPin behavior (not yet).

Item removed.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Do not let urgent matters crowd out time for investment in the future.





^ permalink  raw  reply  [nested|flat] 129+ messages in thread

* Re: First draft of PG 19 release notes
@ 2026-05-26 05:25  Chao Li <li.evan.chao@gmail.com>
  parent: Bruce Momjian <bruce@momjian.us>
  0 siblings, 1 reply; 129+ messages in thread

From: Chao Li @ 2026-05-26 05:25 UTC (permalink / raw)
  To: Bruce Momjian <bruce@momjian.us>; +Cc: Peter Geoghegan <pg@bowt.ie>; PostgreSQL-development <pgsql-hackers@lists.postgresql.org>; chong.peng@enmotech.com



> On May 16, 2026, at 01:27, Bruce Momjian <bruce@momjian.us> wrote:
> 
> On Fri, May 15, 2026 at 12:31:59PM -0400, Peter Geoghegan wrote:
>> On Tue, Apr 14, 2026 at 9:19 PM Bruce Momjian <bruce@momjian.us> wrote:
>>> I have completed the first draft of the PG 19 release notes:
>>> 
>>>        https://www.postgresql.org/docs/devel/release-19.html
>> 
>> I do not think that this item merits mention in the release notes:
>> 
>> "Add fake LSN support to hash index AM (Peter Geoghegan)"
>> 
>> It offers no user-visible benefit. It's just preparation for index
>> prefetching, which didn't make it into Postgres 19.
> 
> Ah, I see your point, and the commit message was clear:
> 
>    This commit is similar to commit 8a879119, which taught nbtree to
>    use fake LSNs to improve its dropPin behavior.  However, unlike that
>    commit, this is not an independently useful enhancement, since hash
>    doesn't implement anything like nbtree's dropPin behavior (not yet).
> 
> Item removed.
> 
> -- 
>  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
>  EDB                                      https://enterprisedb.com
> 
>  Do not let urgent matters crowd out time for investment in the future.
> 
> 

Chong Peng, whom I added to CC, reported this release note issue to me, so I’m just forwarding the message:

```
<listitem>
<para>
Add slot synchronization skip information to pg_stat_replication_slots (Shlok Kyal)
<ulink url="&commit_baseurl;76b78721c">&sect;</ulink>
<ulink url="&commit_baseurl;e68b6adad">&sect;</ulink>
<ulink url="&commit_baseurl;5db6a344a">&sect;</ulink>
</para>

<para>
The new columns are slotsync_skip_count, slotsync_last_skip, and slotsync_skip_reason.
</para>
</listitem>
```

The feature description is inaccurate: slotsync_skip_count and slotsync_last_skip belong to pg_stat_replication_slots, while slotsync_skip_reason belongs to pg_replication_slots. Maybe it could be reworded as:
```
Add slot synchronization skip information to pg_stat_replication_slots and pg_replication_slots (Shlok Kyal)
```

Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/









^ permalink  raw  reply  [nested|flat] 129+ messages in thread

* Re: First draft of PG 19 release notes
@ 2026-05-26 15:00  Bruce Momjian <bruce@momjian.us>
  parent: Chao Li <li.evan.chao@gmail.com>
  0 siblings, 1 reply; 129+ messages in thread

From: Bruce Momjian @ 2026-05-26 15:00 UTC (permalink / raw)
  To: Chao Li <li.evan.chao@gmail.com>; +Cc: Peter Geoghegan <pg@bowt.ie>; PostgreSQL-development <pgsql-hackers@lists.postgresql.org>; chong.peng@enmotech.com

On Tue, May 26, 2026 at 01:25:15PM +0800, Chao Li wrote:
> Chong Peng, whom I added to CC, reported this release note issue to me, so I’m just forwarding the message:
> 
> ```
> <listitem>
> <para>
> Add slot synchronization skip information to pg_stat_replication_slots (Shlok Kyal)
> <ulink url="&commit_baseurl;76b78721c">&sect;</ulink>
> <ulink url="&commit_baseurl;e68b6adad">&sect;</ulink>
> <ulink url="&commit_baseurl;5db6a344a">&sect;</ulink>
> </para>
> 
> <para>
> The new columns are slotsync_skip_count, slotsync_last_skip, and slotsync_skip_reason.
> </para>
> </listitem>
> ```
> 
> The feature description is inaccurate: slotsync_skip_count and slotsync_last_skip belong to pg_stat_replication_slots, while slotsync_skip_reason belongs to pg_replication_slots. Maybe it could be reworded as:
> ```
> Add slot synchronization skip information to pg_stat_replication_slots and pg_replication_slots (Shlok Kyal)
> ```

Yes, very good point.  I missed that detail when merging the commit
items.  I fixed it as you suggested, patch attached.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Do not let urgent matters crowd out time for investment in the future.

Attachments:

  [text/x-diff] master.diff (629B, ../../ahW1hVEIdCzVdklh@momjian.us/2-master.diff)
  download | inline diff:
diff --git a/doc/src/sgml/release-19.sgml b/doc/src/sgml/release-19.sgml
index c8f2b3c6968..f0911b86005 100644
--- a/doc/src/sgml/release-19.sgml
+++ b/doc/src/sgml/release-19.sgml
@@ -1634,7 +1634,7 @@ Author: Amit Kapila <akapila@postgresql.org>
 
 <listitem>
 <para>
-Add slot synchronization skip information to pg_stat_replication_slots (Shlok Kyal)
+Add slot synchronization skip information to pg_stat_replication_slots and pg_replication_slots (Shlok Kyal)
 <ulink url="&commit_baseurl;76b78721c">&sect;</ulink>
 <ulink url="&commit_baseurl;e68b6adad">&sect;</ulink>
 <ulink url="&commit_baseurl;5db6a344a">&sect;</ulink>

^ permalink  raw  reply  [nested|flat] 129+ messages in thread

* Re: First draft of PG 19 release notes
@ 2026-05-26 15:46  Thom Brown <thom@linux.com>
  parent: Bruce Momjian <bruce@momjian.us>
  0 siblings, 1 reply; 129+ messages in thread

From: Thom Brown @ 2026-05-26 15:46 UTC (permalink / raw)
  To: Bruce Momjian <bruce@momjian.us>; +Cc: Chao Li <li.evan.chao@gmail.com>; Peter Geoghegan <pg@bowt.ie>; PostgreSQL-development <pgsql-hackers@lists.postgresql.org>; chong.peng@enmotech.com

On Tue, 26 May 2026 at 16:00, Bruce Momjian <bruce@momjian.us> wrote:
>
> On Tue, May 26, 2026 at 01:25:15PM +0800, Chao Li wrote:
> > Chong Peng, whom I added to CC, reported this release note issue to me, so I’m just forwarding the message:
> >
> > ```
> > <listitem>
> > <para>
> > Add slot synchronization skip information to pg_stat_replication_slots (Shlok Kyal)
> > <ulink url="&commit_baseurl;76b78721c">&sect;</ulink>
> > <ulink url="&commit_baseurl;e68b6adad">&sect;</ulink>
> > <ulink url="&commit_baseurl;5db6a344a">&sect;</ulink>
> > </para>
> >
> > <para>
> > The new columns are slotsync_skip_count, slotsync_last_skip, and slotsync_skip_reason.
> > </para>
> > </listitem>
> > ```
> >
> > The feature description is inaccurate: slotsync_skip_count and slotsync_last_skip belong to pg_stat_replication_slots, while slotsync_skip_reason belongs to pg_replication_slots. Maybe it could be reworded as:
> > ```
> > Add slot synchronization skip information to pg_stat_replication_slots and pg_replication_slots (Shlok Kyal)
> > ```
>
> Yes, very good point.  I missed that detail when merging the commit
> items.  I fixed it as you suggested, patch attached.
>
> --
>   Bruce Momjian  <bruce@momjian.us>        https://momjian.us
>   EDB                                      https://enterprisedb.com
>
>   Do not let urgent matters crowd out time for investment in the future.

Did a review and found a few issues. Attached fixes.

Regards

Thom

Attachments:

  [text/x-patch] release-19-fixes.patch (2.5K, ../../CAA-aLv7w1wwucet76yAW0yq3-LrN5wL81uRrnpT3Tyxh7dmyTw@mail.gmail.com/2-release-19-fixes.patch)
  download | inline diff:
diff --git a/doc/src/sgml/release-19.sgml b/doc/src/sgml/release-19.sgml
index f0911b86005..9aae934215a 100644
--- a/doc/src/sgml/release-19.sgml
+++ b/doc/src/sgml/release-19.sgml
@@ -77,7 +77,7 @@ Issue a warning after successful MD5 password authentication (Nathan Bossart)
 </para>
 
 <para>
-The warning can be disabled via server variable md5_password_warnings.  MD5 passwords were marked marked as deprecated in Postgres 18.
+The warning can be disabled via server variable md5_password_warnings.  MD5 passwords were marked as deprecated in Postgres 18.
 </para>
 </listitem>
 
@@ -144,7 +144,7 @@ Change the default index opclasses for inet and cidr data types from btree_gist
 </para>
 
 <para>
-The btree_gist inet/cidr opclasses are broken because they can exclude rows that should be returned.  Pg_upgrade will fail to upgrade if btree_gist inet/cidr indexes exist in the old
+The btree_gist inet/cidr opclasses are broken because they can exclude rows that should be returned.  pg_upgrade will fail to upgrade if btree_gist inet/cidr indexes exist in the old
 server.
 </para>
 </listitem>
@@ -328,7 +328,7 @@ Author: Richard Guo <rguo@postgresql.org>
 
 <listitem>
 <para>
-Allow NOT INs to be converted to more efficient ANTI JOINs when NULLs are not present (Richard Guo)
+Allow NOT IN clauses to be converted to more efficient anti-joins when NULLs are not present (Richard Guo)
 <ulink url="&commit_baseurl;383eb21eb">&sect;</ulink>
 </para>
 </listitem>
@@ -700,7 +700,7 @@ Author: Nathan Bossart <nathan@postgresql.org>
 
 <listitem>
 <para>
-Improve COPY FROM performance for text and CSV output using SIMD CPU instructions (Nazir Bilal Yavuz, Shinya Kato)
+Improve COPY FROM performance for text and CSV input using SIMD CPU instructions (Nazir Bilal Yavuz, Shinya Kato)
 <ulink url="&commit_baseurl;e0a3a3fd5">&sect;</ulink>
 </para>
 </listitem>
@@ -1210,7 +1210,7 @@ Author: Nathan Bossart <nathan@postgresql.org>
 
 <listitem>
 <para>
-Issue warnings when the wraparound of xid and multi-xids is less then 100 million (Nathan Bossart)
+Issue warnings when the wraparound of xid and multi-xids is less than 100 million (Nathan Bossart)
 <ulink url="&commit_baseurl;48f11bfa0">&sect;</ulink>
 </para>
 
@@ -1588,7 +1588,7 @@ Add subscription option max_retention_duration to limit retain_dead_tuples reten
 </para>
 
 <para>
-When the limit is reached, dead tuple retention until manually re-enabled or a new subscription is created.
+When the limit is reached, dead tuple retention is disabled until manually re-enabled or a new subscription is created.
 </para>
 </listitem>
 


^ permalink  raw  reply  [nested|flat] 129+ messages in thread

* Re: First draft of PG 19 release notes
@ 2026-05-26 20:32  Bruce Momjian <bruce@momjian.us>
  parent: Thom Brown <thom@linux.com>
  0 siblings, 1 reply; 129+ messages in thread

From: Bruce Momjian @ 2026-05-26 20:32 UTC (permalink / raw)
  To: Thom Brown <thom@linux.com>; +Cc: Chao Li <li.evan.chao@gmail.com>; Peter Geoghegan <pg@bowt.ie>; PostgreSQL-development <pgsql-hackers@lists.postgresql.org>; chong.peng@enmotech.com

On Tue, May 26, 2026 at 04:46:12PM +0100, Thom Brown wrote:
> On Tue, 26 May 2026 at 16:00, Bruce Momjian <bruce@momjian.us> wrote:
> Did a review and found a few issues. Attached fixes.

Oh, all very good, applied, thanks.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Do not let urgent matters crowd out time for investment in the future.





^ permalink  raw  reply  [nested|flat] 129+ messages in thread

* Re: First draft of PG 19 release notes
@ 2026-05-26 21:14  Thom Brown <thom@linux.com>
  parent: Bruce Momjian <bruce@momjian.us>
  0 siblings, 1 reply; 129+ messages in thread

From: Thom Brown @ 2026-05-26 21:14 UTC (permalink / raw)
  To: Bruce Momjian <bruce@momjian.us>; +Cc: Chao Li <li.evan.chao@gmail.com>; Peter Geoghegan <pg@bowt.ie>; PostgreSQL-development <pgsql-hackers@lists.postgresql.org>; chong.peng@enmotech.com

On Tue, 26 May 2026 at 21:33, Bruce Momjian <bruce@momjian.us> wrote:
>
> On Tue, May 26, 2026 at 04:46:12PM +0100, Thom Brown wrote:
> > On Tue, 26 May 2026 at 16:00, Bruce Momjian <bruce@momjian.us> wrote:
> > Did a review and found a few issues. Attached fixes.
>
> Oh, all very good, applied, thanks.

I've just spotted that this was a slightly older version of the patch
I had accidentally selected. Attached are the missing changes I had
intended to also send.

Regards

Thom

Attachments:

  [text/x-patch] release-19-fixes-part-2.patch (3.5K, ../../CAA-aLv7B7M9s5fZgCoWzXqer5RJ9jqG_k0h8t5QHFW=Qbxa=Eg@mail.gmail.com/2-release-19-fixes-part-2.patch)
  download | inline diff:
diff --git a/doc/src/sgml/release-19.sgml b/doc/src/sgml/release-19.sgml
index 9aae934215a..6378542b455 100644
--- a/doc/src/sgml/release-19.sgml
+++ b/doc/src/sgml/release-19.sgml
@@ -218,12 +218,12 @@ This means READ ONLY transactions can no longer modify rows processed by postgre
 
 <!--
 Author: Heikki Linnakangas <heikki.linnakangas@iki.fi>
-2026-04-03 [79534f906] Change default of max_locks_per_transactions to 128
+2026-04-03 [79534f906] Change default of max_locks_per_transaction to 128
 -->
 
 <listitem>
 <para>
-Change default of max_locks_per_transactions from 64 to 128 (Heikki Linnakangas)
+Change default of max_locks_per_transaction from 64 to 128 (Heikki Linnakangas)
 <ulink url="&commit_baseurl;79534f906">&sect;</ulink>
 </para>
 
@@ -1619,7 +1619,7 @@ Rename column sync_error_count to sync_table_error_count in system view pg_stat_
 </para>
 
 <para>
-This is necessary since sequences errors are now also tracked.
+This is necessary since sequence errors are now also tracked.
 </para>
 </listitem>
 
@@ -1747,7 +1747,7 @@ Author: Dean Rasheed <dean.a.rasheed@gmail.com>
 
 <listitem>
 <para>
-Add support for INSERT ... ON CONFLICT DO SELECT ... RETURNING (Andreas Karlsson,  Marko Tiikkaja, Viktor Holmberg)
+Add support for INSERT ... ON CONFLICT DO SELECT ... RETURNING (Andreas Karlsson, Marko Tiikkaja, Viktor Holmberg)
 <ulink url="&commit_baseurl;88327092f">&sect;</ulink>
 </para>
 
@@ -1798,7 +1798,7 @@ Allow REPACK to rebuild tables without access-exclusive locking (Antonin Houska,
 </para>
 
 <para>
-This is enabled via the CONCURRENTLY option.  Server variables max_repack_replication_slots was also added.
+This is enabled via the CONCURRENTLY option.  Server variable max_repack_replication_slots was also added.
 </para>
 </listitem>
 
@@ -1961,7 +1961,7 @@ Author: Fujii Masao <fujii@postgresql.org>
 
 <listitem>
 <para>
-Allow multiple headers lines be skipped by COPY FROM (Shinya Kato, Fujii Masao)
+Allow multiple headers lines to be skipped by COPY FROM (Shinya Kato, Fujii Masao)
 <ulink url="&commit_baseurl;bc2f348e8">&sect;</ulink>
 </para>
 
@@ -2217,7 +2217,7 @@ Add functions to return a set of ranges resulting from range subtraction (Paul A
 </para>
 
 <para>
-The functions are range_minus_multi() and multirange_minus_multi().  This is useful to represent range subtractions results with gaps.
+The functions are range_minus_multi() and multirange_minus_multi().  This is useful to represent range subtraction results with gaps.
 </para>
 </listitem>
 
@@ -2245,7 +2245,7 @@ Allow IS JSON to work on domains defined over supported base types (Jian He)
 </para>
 
 <para>
-The supported base domains are TEXT, JSON, JSONB, and BYTEA.
+The supported base types are TEXT, JSON, JSONB, and BYTEA.
 </para>
 </listitem>
 
@@ -2424,7 +2424,7 @@ Author: Jacob Champion <jchampion@postgresql.org>
 
 <listitem>
 <para>
-Allow libpq environment variable PGOAUTHDEBUG to specify specific debug options (Zsolt Parragi, Jacob Champion)
+Allow libpq environment variable PGOAUTHDEBUG to specify particular debug options (Zsolt Parragi, Jacob Champion)
 <ulink url="&commit_baseurl;6d00fb904">&sect;</ulink>
 </para>
 
@@ -2690,7 +2690,7 @@ Author: Andrew Dunstan <andrew@dunslane.net>
 
 <listitem>
 <para>
-Allow pg_dumpall to product output in non-text formats (Mahendra Singh Thalor, Andrew Dunstan)
+Allow pg_dumpall to produce output in non-text formats (Mahendra Singh Thalor, Andrew Dunstan)
 <ulink url="&commit_baseurl;763aaa06f">&sect;</ulink>
 <ulink url="&commit_baseurl;3c19983cc">&sect;</ulink>
 </para>


^ permalink  raw  reply  [nested|flat] 129+ messages in thread

* Re: First draft of PG 19 release notes
@ 2026-05-26 21:49  Bruce Momjian <bruce@momjian.us>
  parent: Thom Brown <thom@linux.com>
  0 siblings, 0 replies; 129+ messages in thread

From: Bruce Momjian @ 2026-05-26 21:49 UTC (permalink / raw)
  To: Thom Brown <thom@linux.com>; +Cc: Chao Li <li.evan.chao@gmail.com>; Peter Geoghegan <pg@bowt.ie>; PostgreSQL-development <pgsql-hackers@lists.postgresql.org>; chong.peng@enmotech.com

On Tue, May 26, 2026 at 10:14:32PM +0100, Thom Brown wrote:
> On Tue, 26 May 2026 at 21:33, Bruce Momjian <bruce@momjian.us> wrote:
> >
> > On Tue, May 26, 2026 at 04:46:12PM +0100, Thom Brown wrote:
> > > On Tue, 26 May 2026 at 16:00, Bruce Momjian <bruce@momjian.us> wrote:
> > > Did a review and found a few issues. Attached fixes.
> >
> > Oh, all very good, applied, thanks.
> 
> I've just spotted that this was a slightly older version of the patch
> I had accidentally selected. Attached are the missing changes I had
> intended to also send.

Wow, thanks for the additional fixes, applied.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Do not let urgent matters crowd out time for investment in the future.





^ permalink  raw  reply  [nested|flat] 129+ messages in thread

* Re: First draft of PG 19 release notes
@ 2026-05-29 03:30  =?utf-8?B?5b2t5Yay?= <chong.peng@enmotech.com>
  0 siblings, 1 reply; 129+ messages in thread

From: 彭冲 @ 2026-05-29 03:30 UTC (permalink / raw)
  To: bruce <bruce@momjian.us>; +Cc: Peter Geoghegan <pg@bowt.ie>; PostgreSQL-development <pgsql-hackers@lists.postgresql.org>; Chao Li <li.evan.chao@gmail.com>

Hi, Bruce



```


                    <listitem&gt; <para&gt; Modify pg_read_all_data() and pg_write_all_data() to read/write large objects (Nitin Motiani, Nathan Bossart) <ulink url="&amp;commit_baseurl;d98197602"&gt;&amp;sect;</ulink&gt; </para&gt; <para&gt; These functions are designed to allow non-super users to run pg_dump. </para&gt; </listitem&gt;```
I found the feature description is inaccurate.: “pg_read_all_data” and “pg_write_all_data” are system roles.


Besides, i think this feature should not category to Functions.


Best regards,--
Chong Peng
Yunhe Enmo（Beijing）Technology Co.,LTD
http://www.enmotech.com/

^ permalink  raw  reply  [nested|flat] 129+ messages in thread

* Re: First draft of PG 19 release notes
@ 2026-05-30 18:57  Bruce Momjian <bruce@momjian.us>
  parent: =?utf-8?B?5b2t5Yay?= <chong.peng@enmotech.com>
  0 siblings, 0 replies; 129+ messages in thread

From: Bruce Momjian @ 2026-05-30 18:57 UTC (permalink / raw)
  To: 彭冲 <chong.peng@enmotech.com>; +Cc: Peter Geoghegan <pg@bowt.ie>; PostgreSQL-development <pgsql-hackers@lists.postgresql.org>; Chao Li <li.evan.chao@gmail.com>

On Fri, May 29, 2026 at 11:30:28AM +0800, 彭冲 wrote:
> Hi, Bruce
> 
> ```
> 
> <listitem>
> <para>
> Modify pg_read_all_data() and pg_write_all_data() to read/write large objects (Nitin Motiani, Nathan Bossart)
> <ulink url="&commit_baseurl;d98197602">&sect;</ulink>
> </para>
> 
> <para>
> These functions are designed to allow non-super users to run pg_dump.
> </para>
> </listitem>
> 
> ```
> 
> 
> I found the feature description is inaccurate.: “pg_read_all_data” and “pg_write_all_data” are system roles.
> 
> Besides, i think this feature should not category to Functions.

Ah, very good point.  It item reworded and moved to the server
configuration section.  Patch attached and applied.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Do not let urgent matters crowd out time for investment in the future.

Attachments:

  [text/x-diff] master.diff (1.9K, ../../ahszC5QE2aRMJqf7@momjian.us/2-master.diff)
  download | inline diff:
commit 3e744cc745b
Author: Bruce Momjian <bruce@momjian.us>
Date:   Sat May 30 14:55:32 2026 -0400

    doc PG 19 relnotes:  adjust pg_read_all_data & pg_write_all_data
    
    These were previously marked as functions, not roles, and were in the
    wrong section.
    
    Reported-by: 彭冲 <chong.peng@enmotech.com>
    
    Discussion: https://postgr.es/m/tencent_5468291122A490C6578D9467@qq.com

diff --git a/doc/src/sgml/release-19.sgml b/doc/src/sgml/release-19.sgml
index 6378542b455..ee063d2417e 100644
--- a/doc/src/sgml/release-19.sgml
+++ b/doc/src/sgml/release-19.sgml
@@ -1298,6 +1298,22 @@ This is an improved version of PQAUTHDATA_OAUTH_BEARER_TOKEN by adding the issue
 </para>
 </listitem>
 
+<!--
+Author: Nathan Bossart <nathan@postgresql.org>
+2026-02-23 [d98197602] Allow pg_{read,write}_all_data to access large objects.
+-->
+
+<listitem>
+<para>
+Allow roles pg_read_all_data and pg_write_all_data to read/write large objects (Nitin Motiani, Nathan Bossart)
+<ulink url="&commit_baseurl;d98197602">&sect;</ulink>
+</para>
+
+<para>
+These roles are designed to allow non-super users to run pg_dump.
+</para>
+</listitem>
+
 <!--
 Author: Michael Paquier <michael@paquier.xyz>
 2026-01-06 [f1e251be8] Allow bgworkers to be terminated for database-related co
@@ -2265,22 +2281,6 @@ The Dutch stemmer has also been updated.  The old Dutch stemmer is available via
 </para>
 </listitem>
 
-<!--
-Author: Nathan Bossart <nathan@postgresql.org>
-2026-02-23 [d98197602] Allow pg_{read,write}_all_data to access large objects.
--->
-
-<listitem>
-<para>
-Modify pg_read_all_data() and pg_write_all_data() to read/write large objects (Nitin Motiani, Nathan Bossart)
-<ulink url="&commit_baseurl;d98197602">&sect;</ulink>
-</para>
-
-<para>
-These functions are designed to allow non-super users to run pg_dump.
-</para>
-</listitem>
-
 <!--
 Author: Andrew Dunstan <andrew@dunslane.net>
 2026-04-05 [76e514ebb] Add pg_get_role_ddl() function

^ permalink  raw  reply  [nested|flat] 129+ messages in thread

* Re: First draft of PG 19 release notes
@ 2026-06-04 00:51  =?utf-8?B?5b2t5Yay?= <chong.peng@enmotech.com>
  0 siblings, 1 reply; 129+ messages in thread

From: 彭冲 @ 2026-06-04 00:51 UTC (permalink / raw)
  To: bruce <bruce@momjian.us>; +Cc: PostgreSQL-development <pgsql-hackers@lists.postgresql.org>

Hi, Bruce



```



                    <para&gt; Previously <acronym&gt;JIT</acronym&gt; was enabled by default, and activated based on optimizer costs, but this costing has been determined to be unreliable. &nbsp;This this change requires sites that are doing many large analytical queries to manually enable <acronym&gt;JIT</acronym&gt;. </para&gt;```
This this, double "this".




Best regards,--
Chong Peng
Yunhe Enmo（Beijing）Technology Co.,LTD
http://www.enmotech.com/

^ permalink  raw  reply  [nested|flat] 129+ messages in thread

* Re: First draft of PG 19 release notes
@ 2026-06-04 02:27  Bruce Momjian <bruce@momjian.us>
  parent: =?utf-8?B?5b2t5Yay?= <chong.peng@enmotech.com>
  0 siblings, 0 replies; 129+ messages in thread

From: Bruce Momjian @ 2026-06-04 02:27 UTC (permalink / raw)
  To: 彭冲 <chong.peng@enmotech.com>; +Cc: PostgreSQL-development <pgsql-hackers@lists.postgresql.org>

On Thu, Jun  4, 2026 at 08:51:58AM +0800, 彭冲 wrote:
> Hi, Bruce
> 
> ```
> 
> <para>
> Previously <acronym>JIT</acronym> was enabled by default, and activated based on optimizer costs, but this costing has been determined to be unreliable.  This this change requires sites that are doing many
> large analytical queries to manually enable <acronym>JIT</acronym>.
> </para>
> 
> ```
> 
> 
> This this, double "this".

Thanks, will fix.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Do not let urgent matters crowd out time for investment in the future.





^ permalink  raw  reply  [nested|flat] 129+ messages in thread

* Re: First draft of PG 19 release notes
@ 2026-06-05 08:11  Yugo Nagata <nagata@sraoss.co.jp>
  parent: Bruce Momjian <bruce@momjian.us>
  25 siblings, 1 reply; 129+ messages in thread

From: Yugo Nagata @ 2026-06-05 08:11 UTC (permalink / raw)
  To: Bruce Momjian <bruce@momjian.us>; +Cc: PostgreSQL-development <pgsql-hackers@lists.postgresql.org>

Hi,

On Tue, 14 Apr 2026 21:18:57 -0400
Bruce Momjian <bruce@momjian.us> wrote:

> I have completed the first draft of the PG 19 release notes:
> 
> 	https://www.postgresql.org/docs/devel/release-19.html

I noticed duplicate names in the psql tab completion improvement entry.
Yugo Nagata and Fujii Masao each appear twice.

If this is not intentional, we could remove the duplicates as in the attached patch.

Regareds,
Yugo Nagata

-- 
Yugo Nagata <nagata@sraoss.co.jp>

Attachments:

  [text/x-diff] release_remove_duplicate_name.patch (892B, ../../20260605171108.64f79002de99f302d13d5416@sraoss.co.jp/2-release_remove_duplicate_name.patch)
  download | inline diff:
diff --git a/doc/src/sgml/release-19.sgml b/doc/src/sgml/release-19.sgml
index 0dd2ee580c9..52521cf37de 100644
--- a/doc/src/sgml/release-19.sgml
+++ b/doc/src/sgml/release-19.sgml
@@ -2559,7 +2559,7 @@ Author: Álvaro Herrera <alvherre@kurilemu.de>
 
 <listitem>
 <para>
-Add or improve <link linkend="app-psql"><application>psql</application></link> tab completion (Yamaguchi Atsuo, Yugo Nagata, Haruna Miwa, Xuneng Zhou, Yugo Nagata, Dagfinn Ilmari Mannsåker, Fujii Masao, Álvaro Herrera, Jian He, Fujii Masao,
+Add or improve <link linkend="app-psql"><application>psql</application></link> tab completion (Yamaguchi Atsuo, Yugo Nagata, Haruna Miwa, Xuneng Zhou, Dagfinn Ilmari Mannsåker, Fujii Masao, Álvaro Herrera, Jian He,
 Tatsuya Kawata, Ian Lawrence Barwick, Vasuki M)
 <ulink url="&commit_baseurl;5fa7837d9">&sect;</ulink>
 <ulink url="&commit_baseurl;c6a7d3bab">&sect;</ulink>

^ permalink  raw  reply  [nested|flat] 129+ messages in thread

* Re: First draft of PG 19 release notes
@ 2026-06-05 13:55  Bruce Momjian <bruce@momjian.us>
  parent: Yugo Nagata <nagata@sraoss.co.jp>
  0 siblings, 1 reply; 129+ messages in thread

From: Bruce Momjian @ 2026-06-05 13:55 UTC (permalink / raw)
  To: Yugo Nagata <nagata@sraoss.co.jp>; +Cc: PostgreSQL-development <pgsql-hackers@lists.postgresql.org>

On Fri, Jun  5, 2026 at 05:11:08PM +0900, Yugo Nagata wrote:
> Hi,
> 
> On Tue, 14 Apr 2026 21:18:57 -0400
> Bruce Momjian <bruce@momjian.us> wrote:
> 
> > I have completed the first draft of the PG 19 release notes:
> > 
> > 	https://www.postgresql.org/docs/devel/release-19.html
> 
> I noticed duplicate names in the psql tab completion improvement entry.
> Yugo Nagata and Fujii Masao each appear twice.
> 
> If this is not intentional, we could remove the duplicates as in the attached patch.

Yes, my mistake, will fix, thanks.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Do not let urgent matters crowd out time for investment in the future.





^ permalink  raw  reply  [nested|flat] 129+ messages in thread

* Re: First draft of PG 19 release notes
@ 2026-06-05 18:14  Bruce Momjian <bruce@momjian.us>
  parent: Bruce Momjian <bruce@momjian.us>
  0 siblings, 1 reply; 129+ messages in thread

From: Bruce Momjian @ 2026-06-05 18:14 UTC (permalink / raw)
  To: Yugo Nagata <nagata@sraoss.co.jp>; +Cc: PostgreSQL-development <pgsql-hackers@lists.postgresql.org>

On Fri, Jun  5, 2026 at 09:55:27AM -0400, Bruce Momjian wrote:
> On Fri, Jun  5, 2026 at 05:11:08PM +0900, Yugo Nagata wrote:
> > Hi,
> > 
> > On Tue, 14 Apr 2026 21:18:57 -0400
> > Bruce Momjian <bruce@momjian.us> wrote:
> > 
> > > I have completed the first draft of the PG 19 release notes:
> > > 
> > > 	https://www.postgresql.org/docs/devel/release-19.html
> > 
> > I noticed duplicate names in the psql tab completion improvement entry.
> > Yugo Nagata and Fujii Masao each appear twice.
> > 
> > If this is not intentional, we could remove the duplicates as in the attached patch.
> 
> Yes, my mistake, will fix, thanks.

I want to thank everyone for the fixes/improvements they have supplied
for the PG 19 release notes.  I am now satisfied with them and I think
they are close to what they will look link for PG 19 final. Here are the
current contents:

	https://www.postgresql.org/docs/19/release-19.html

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Do not let urgent matters crowd out time for investment in the future.





^ permalink  raw  reply  [nested|flat] 129+ messages in thread

* Re: First draft of PG 19 release notes
@ 2026-06-05 18:58  Bruce Momjian <bruce@momjian.us>
  parent: Bruce Momjian <bruce@momjian.us>
  0 siblings, 2 replies; 129+ messages in thread

From: Bruce Momjian @ 2026-06-05 18:58 UTC (permalink / raw)
  To: Yugo Nagata <nagata@sraoss.co.jp>; +Cc: PostgreSQL-development <pgsql-hackers@lists.postgresql.org>

On Fri, Jun  5, 2026 at 02:14:21PM -0400, Bruce Momjian wrote:
> On Fri, Jun  5, 2026 at 09:55:27AM -0400, Bruce Momjian wrote:
> > On Fri, Jun  5, 2026 at 05:11:08PM +0900, Yugo Nagata wrote:
> > > Hi,
> > > 
> > > On Tue, 14 Apr 2026 21:18:57 -0400
> > > Bruce Momjian <bruce@momjian.us> wrote:
> > > 
> > > > I have completed the first draft of the PG 19 release notes:
> > > > 
> > > > 	https://www.postgresql.org/docs/devel/release-19.html
> > > 
> > > I noticed duplicate names in the psql tab completion improvement entry.
> > > Yugo Nagata and Fujii Masao each appear twice.
> > > 
> > > If this is not intentional, we could remove the duplicates as in the attached patch.
> > 
> > Yes, my mistake, will fix, thanks.
> 
> I want to thank everyone for the fixes/improvements they have supplied
> for the PG 19 release notes.  I am now satisfied with them and I think
> they are close to what they will look link for PG 19 final. Here are the
> current contents:
> 
> 	https://www.postgresql.org/docs/19/release-19.html

My apologies, this is the old version;  the most current version is
here:

	https://momjian.us/pgsql_docs/release-19.html

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Do not let urgent matters crowd out time for investment in the future.





^ permalink  raw  reply  [nested|flat] 129+ messages in thread

* Re: First draft of PG 19 release notes
@ 2026-06-05 19:17  Baji Shaik <baji.pgdev@gmail.com>
  parent: Bruce Momjian <bruce@momjian.us>
  1 sibling, 1 reply; 129+ messages in thread

From: Baji Shaik @ 2026-06-05 19:17 UTC (permalink / raw)
  To: Bruce Momjian <bruce@momjian.us>; +Cc: Yugo Nagata <nagata@sraoss.co.jp>; PostgreSQL-development <pgsql-hackers@lists.postgresql.org>

On Fri, Jun 5, 2026 at 1:58 PM Bruce Momjian <bruce@momjian.us> wrote:

> My apologies, this is the old version;  the most current version is
> here:
>
>         https://momjian.us/pgsql_docs/release-19.html


Can e5035950dab ("psql: Fix tab completion for REPACK boolean options")
also be part of the notes?
https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=e5035950dab

^ permalink  raw  reply  [nested|flat] 129+ messages in thread

* Re: First draft of PG 19 release notes
@ 2026-06-05 19:29  Bruce Momjian <bruce@momjian.us>
  parent: Baji Shaik <baji.pgdev@gmail.com>
  0 siblings, 0 replies; 129+ messages in thread

From: Bruce Momjian @ 2026-06-05 19:29 UTC (permalink / raw)
  To: Baji Shaik <baji.pgdev@gmail.com>; +Cc: Yugo Nagata <nagata@sraoss.co.jp>; PostgreSQL-development <pgsql-hackers@lists.postgresql.org>

On Fri, Jun  5, 2026 at 02:17:01PM -0500, Baji Shaik wrote:
> 
> 
> On Fri, Jun 5, 2026 at 1:58 PM Bruce Momjian <bruce@momjian.us> wrote:
> 
>     My apologies, this is the old version;  the most current version is
>     here:
> 
>             https://momjian.us/pgsql_docs/release-19.html
> 
> 
> Can e5035950dab ("psql: Fix tab completion for REPACK boolean options")
> also be part of the notes?
> https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=e5035950dab

Uh, I don't add tab fixes for new commands in the release note.  I am
more focused on adding changes for tab completion for existing commands,
though I tend to add them on the first pass but not in later months.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Do not let urgent matters crowd out time for investment in the future.





^ permalink  raw  reply  [nested|flat] 129+ messages in thread

* Re: First draft of PG 19 release notes
@ 2026-06-06 13:08  Álvaro Herrera <alvherre@kurilemu.de>
  parent: Bruce Momjian <bruce@momjian.us>
  1 sibling, 1 reply; 129+ messages in thread

From: Álvaro Herrera @ 2026-06-06 13:08 UTC (permalink / raw)
  To: Bruce Momjian <bruce@momjian.us>; +Cc: Yugo Nagata <nagata@sraoss.co.jp>; PostgreSQL-development <pgsql-hackers@lists.postgresql.org>

On 2026-Jun-05, Bruce Momjian wrote:

> > I want to thank everyone for the fixes/improvements they have supplied
> > for the PG 19 release notes.  I am now satisfied with them and I think
> > they are close to what they will look link for PG 19 final. Here are the
> > current contents:

> 	https://momjian.us/pgsql_docs/release-19.html

Thanks for putting these together!  I have a few comments:

* In the incompatibilities section, we have
  - Prevent carriage returns and line feeds in database, role, and
  tablespace names

  This was changed to avoid security problems. pg_upgrade will also
  disallow upgrading of clusters that use such names.

  The verb "prevent" here is a bit strange; I think "reject" would be
  better.  Also, I think the phrase involving pg_upgrade should come
  before the reason for the change.

  We also have this item:

  Change the default index opclasses for inet and cidr data types from
  btree_gist to GiST

  The btree_gist inet/cidr opclasses are broken because they can exclude
  rows that should be returned. pg_upgrade will fail to upgrade if
  btree_gist inet/cidr indexes exist in the old server.

  Why do we say "pg_upgrade will fail to upgrade" here instead of the
  (IMO better) wording in the previous item?  That is, "pg_upgrade will
  disallow upgrading if btree_gist inet/cidr indexes exist in the old
  server".  The current wording of "fail to" suggest that this is a
  pg_upgrade shortcoming, which it isn't.


* In section E.1.3.1.1 Optimizer, I think the item
  "Allow extended statistics on virtual generated columns"
  should come before all other items, because it's the only one that
  requires user action in order for them to take advantage of it.  All
  the other items refer to some optimization that occurs automatically.

* Section E.1.3.1.2 General Performance, the item
  Allow autovacuum to use parallel vacuum workers
  lacks a link to
  https://momjian.us/pgsql_docs/sql-createtable.html#RELOPTION-AUTOVACUUM-PARALLEL-WORKERS

* Section E.1.3.1.3 System Views, the two items
  Add vacuum initiation details to system view pg_stat_progress_vacuum
  Add analyze initiation details to system view pg_stat_progress_analyze
  Maybe they should be a single entry?
  Add vacuum and analyze initiation details to system view
  pg_stat_progress_vacuum and pg_stat_progress_analyze respectively
  (Not really sure about this one)
 
* E.1.3.1.4 Monitoring
  Add server variable log_autoanalyze_min_duration to log long-running
  autoanalyze operations (Shinya Kato) §
  Server variable log_autovacuum_min_duration now only controls logging
  of autovacuum operations.

  I think it's confusing to talk about "autoanalyze" as if it were
  an action taken by an agent other than autovacuum.  I mean, we have
  autovacuum which runs autovacuums and also autovacuum which runs
  autoanalyzes?  To my mind that makes no sense -- I think we have one
  autovacuum, which runs vacuum and analyze.

  I would explain this as
  Add server variable log_autoanalyze_min_duration to log long-running
  analyze operations run by autovacuum (Shinya Kato) §
  Server variable log_autovacuum_min_duration now only controls logging
  of vacuum operations run by autovacuum.

  * Add WAL full-page write bytes reporting to VACUUM and ANALYZE logging
  (Shinya Kato) §
  Maybe this should be "Report bytes of full-page WAL writes to VACUUM
  and ANALYZE logging".
  (This also appears in E.1.3.3.3 EXPLAIN and E.1.3.1.3 System Views)

  * Add function pg_get_multixact_stats() to report multixact activity
  (Naga Appani) §
  I think this item should appear second in the section, right after the
  one for log_min_messages, on importance grounds.

  * Two entries make the acronym LSN point to 
  https://momjian.us/pgsql_docs/wal-internals.html
  I think a better target is the glossary item
  https://momjian.us/pgsql_docs/glossary.html#GLOSSARY-LOG-SEQUENCE-NUMBER
  The shorter definition in the glossary is possibly more useful for a
  release note reader; and if they want even more detail, the glossary
  definition does point to the WAL internals.
  A third entry appears in E.1.3.1.6

* E.1.3.1.5 Server Configuration
  * Allow online enabling and disabling of data checksums
  Previously the checksum status could only be set at initialization and
  changed only while the cluster was offline using pg_checksums.

  The word "only" appears twice in the second phrase, which is awkward.
  Maybe reword it as
  Previously the checksum status would be fixed at initialization time and
  only changed while the cluster was offline usiNG PG_checksums.

  * Add scoring system to control the order that tables are autovacuumed
  I think using "autovacuumed" as a verb is terrible grammar.  I would
  rather have "... are processed by autovacuum".
  
  * Allow background workers to be configured to terminate before
  database-level operations (Aya Iwata) §
  This sounds far too mysterious; it probably warrants more detail.
  Also, move it a bit upwards: just below SNI perhaps?  (That isn't
  much, but all the other items in this section also look valuable.)

* E.1.3.3.2 Copy
  * Allow COPY TO to output partitioned tables (Jian He, Ajin Cherian) § §
  "to output partitioned tables"?  This reads really awkward.
  What about ... "Allow partitioned tables to be [processed / read] by
  COPY TO directly" or something like that?


-- 
Álvaro Herrera         PostgreSQL Developer  —  https://www.EnterpriseDB.com/
"La vida es para el que se aventura"





^ permalink  raw  reply  [nested|flat] 129+ messages in thread

* Re: First draft of PG 19 release notes
@ 2026-06-08 03:43  Bruce Momjian <bruce@momjian.us>
  parent: Álvaro Herrera <alvherre@kurilemu.de>
  0 siblings, 1 reply; 129+ messages in thread

From: Bruce Momjian @ 2026-06-08 03:43 UTC (permalink / raw)
  To: Álvaro Herrera <alvherre@kurilemu.de>; +Cc: Yugo Nagata <nagata@sraoss.co.jp>; PostgreSQL-development <pgsql-hackers@lists.postgresql.org>

On Sat, Jun  6, 2026 at 03:08:05PM +0200, Álvaro Herrera wrote:
> On 2026-Jun-05, Bruce Momjian wrote:
> 
> > > I want to thank everyone for the fixes/improvements they have supplied
> > > for the PG 19 release notes.  I am now satisfied with them and I think
> > > they are close to what they will look link for PG 19 final. Here are the
> > > current contents:
> 
> > 	https://momjian.us/pgsql_docs/release-19.html
> 
> Thanks for putting these together!  I have a few comments:
> 
> * In the incompatibilities section, we have
>   - Prevent carriage returns and line feeds in database, role, and
>   tablespace names
> 
>   This was changed to avoid security problems. pg_upgrade will also
>   disallow upgrading of clusters that use such names.
> 
>   The verb "prevent" here is a bit strange; I think "reject" would be
>   better.  Also, I think the phrase involving pg_upgrade should come
>   before the reason for the change.

Agreed.  I went with "Disallow carriage returns and line feeds", and I
moved the security text to the end as you suggested.

> 
>   We also have this item:
> 
>   Change the default index opclasses for inet and cidr data types from
>   btree_gist to GiST
> 
>   The btree_gist inet/cidr opclasses are broken because they can exclude
>   rows that should be returned. pg_upgrade will fail to upgrade if
>   btree_gist inet/cidr indexes exist in the old server.
> 
>   Why do we say "pg_upgrade will fail to upgrade" here instead of the
>   (IMO better) wording in the previous item?  That is, "pg_upgrade will
>   disallow upgrading if btree_gist inet/cidr indexes exist in the old
>   server".  The current wording of "fail to" suggest that this is a
>   pg_upgrade shortcoming, which it isn't.

I went with similar wording "pg_upgrade will disallow upgrading".

> * In section E.1.3.1.1 Optimizer, I think the item
>   "Allow extended statistics on virtual generated columns"
>   should come before all other items, because it's the only one that
>   requires user action in order for them to take advantage of it.  All
>   the other items refer to some optimization that occurs automatically.

While the first item in each section is the most important, I then list
later items in groups that have similar characteristics, which I think
simplifies reading.  While I could order all items in importance order,
I think it would be much more confusing to read.  Right now the item you
mention is in a group of items about optimizer statistics.

> * Section E.1.3.1.2 General Performance, the item
>   Allow autovacuum to use parallel vacuum workers
>   lacks a link to
>   https://momjian.us/pgsql_docs/sql-createtable.html#RELOPTION-AUTOVACUUM-PARALLEL-WORKERS

Added link.

> * Section E.1.3.1.3 System Views, the two items
>   Add vacuum initiation details to system view pg_stat_progress_vacuum
>   Add analyze initiation details to system view pg_stat_progress_analyze
>   Maybe they should be a single entry?
>   Add vacuum and analyze initiation details to system view
>   pg_stat_progress_vacuum and pg_stat_progress_analyze respectively
>   (Not really sure about this one)

I looked at merging these before, and the existence of the "mode" column
in vacuum but not analyze made the merged item too complicated to
understand.

> * E.1.3.1.4 Monitoring
>   Add server variable log_autoanalyze_min_duration to log long-running
>   autoanalyze operations (Shinya Kato) §
>   Server variable log_autovacuum_min_duration now only controls logging
>   of autovacuum operations.
> 
>   I think it's confusing to talk about "autoanalyze" as if it were
>   an action taken by an agent other than autovacuum.  I mean, we have
>   autovacuum which runs autovacuums and also autovacuum which runs
>   autoanalyzes?  To my mind that makes no sense -- I think we have one
>   autovacuum, which runs vacuum and analyze.
> 
>   I would explain this as
>   Add server variable log_autoanalyze_min_duration to log long-running
>   analyze operations run by autovacuum (Shinya Kato) §
>   Server variable log_autovacuum_min_duration now only controls logging
>   of vacuum operations run by autovacuum.

Well, the column calls it autoanalyze, but I agree when we are talking
about the tool, autovacuum is better, so changed.

>   * Add WAL full-page write bytes reporting to VACUUM and ANALYZE logging
>   (Shinya Kato) §
>   Maybe this should be "Report bytes of full-page WAL writes to VACUUM
>   and ANALYZE logging".
>   (This also appears in E.1.3.3.3 EXPLAIN and E.1.3.1.3 System Views)

Yes, saying "Add reporting of X" is better than "add X reporting";  fixed
in both cases.

>   * Add function pg_get_multixact_stats() to report multixact activity
>   (Naga Appani) §
>   I think this item should appear second in the section, right after the
>   one for log_min_messages, on importance grounds.

Again, already grouped in a section about monitoring functions, and I do
think the earlier items are more important.

>   * Two entries make the acronym LSN point to 
>   https://momjian.us/pgsql_docs/wal-internals.html
>   I think a better target is the glossary item
>   https://momjian.us/pgsql_docs/glossary.html#GLOSSARY-LOG-SEQUENCE-NUMBER
>   The shorter definition in the glossary is possibly more useful for a
>   release note reader; and if they want even more detail, the glossary
>   definition does point to the WAL internals.
>   A third entry appears in E.1.3.1.6

Well, the second paragraph does explain LSN so I think pointing them to
a glossary makes things worse.

> * E.1.3.1.5 Server Configuration
>   * Allow online enabling and disabling of data checksums
>   Previously the checksum status could only be set at initialization and
>   changed only while the cluster was offline using pg_checksums.
> 
>   The word "only" appears twice in the second phrase, which is awkward.
>   Maybe reword it as
>   Previously the checksum status would be fixed at initialization time and
>   only changed while the cluster was offline usiNG PG_checksums.

Yes, and the bigger problem is that there is no need to mention
initialization setting of checksums, so the first part of the sentence
is now gone.

>   * Add scoring system to control the order that tables are autovacuumed
>   I think using "autovacuumed" as a verb is terrible grammar.  I would
>   rather have "... are processed by autovacuum".

Yes, agreed, fixed.

>   * Allow background workers to be configured to terminate before
>   database-level operations (Aya Iwata) §
>   This sounds far too mysterious; it probably warrants more detail.
>   Also, move it a bit upwards: just below SNI perhaps?  (That isn't
>   much, but all the other items in this section also look valuable.)

Agreed.  I added a sentence to explain its purpose.

> * E.1.3.3.2 Copy
>   * Allow COPY TO to output partitioned tables (Jian He, Ajin Cherian) § §
>   "to output partitioned tables"?  This reads really awkward.
>   What about ... "Allow partitioned tables to be [processed / read] by
>   COPY TO directly" or something like that?

Yes, I used "process".  New output here:

	https://momjian.us/pgsql_docs/release-19.html

You certainly found some confusing items and I like the new output.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Do not let urgent matters crowd out time for investment in the future.





^ permalink  raw  reply  [nested|flat] 129+ messages in thread

* Re: First draft of PG 19 release notes
@ 2026-06-08 14:13  Bruce Momjian <bruce@momjian.us>
  parent: Bruce Momjian <bruce@momjian.us>
  0 siblings, 1 reply; 129+ messages in thread

From: Bruce Momjian @ 2026-06-08 14:13 UTC (permalink / raw)
  To: Álvaro Herrera <alvherre@kurilemu.de>; +Cc: Yugo Nagata <nagata@sraoss.co.jp>; PostgreSQL-development <pgsql-hackers@lists.postgresql.org>

On Sun, Jun  7, 2026 at 11:43:16PM -0400, Bruce Momjian wrote:
> > * In section E.1.3.1.1 Optimizer, I think the item
> >   "Allow extended statistics on virtual generated columns"
> >   should come before all other items, because it's the only one that
> >   requires user action in order for them to take advantage of it.  All
> >   the other items refer to some optimization that occurs automatically.
> 
> While the first item in each section is the most important, I then list
> later items in groups that have similar characteristics, which I think
> simplifies reading.  While I could order all items in importance order,
> I think it would be much more confusing to read.  Right now the item you
> mention is in a group of items about optimizer statistics.

Actually, if there is no "most important" item in a section, I just
order by placing the largest group of similar items first.  Here are the
detais:

	https://wiki.postgresql.org/wiki/Creating_Major_Release_Notes
	order inside of sections
	               most important item first in section
	                  if none, then largest group first
	               group similar items together
	               order group by item importance
	               ideally the last item in a group will relate to the first item in the next group

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Do not let urgent matters crowd out time for investment in the future.





^ permalink  raw  reply  [nested|flat] 129+ messages in thread

* Re: First draft of PG 19 release notes
@ 2026-06-09 06:59  Chao Li <li.evan.chao@gmail.com>
  parent: Bruce Momjian <bruce@momjian.us>
  0 siblings, 1 reply; 129+ messages in thread

From: Chao Li @ 2026-06-09 06:59 UTC (permalink / raw)
  To: Bruce Momjian <bruce@momjian.us>; +Cc: PostgreSQL-development <pgsql-hackers@lists.postgresql.org>



> On Jun 8, 2026, at 22:13, Bruce Momjian <bruce@momjian.us> wrote:
> 
> On Sun, Jun  7, 2026 at 11:43:16PM -0400, Bruce Momjian wrote:
>>> * In section E.1.3.1.1 Optimizer, I think the item
>>>  "Allow extended statistics on virtual generated columns"
>>>  should come before all other items, because it's the only one that
>>>  requires user action in order for them to take advantage of it.  All
>>>  the other items refer to some optimization that occurs automatically.
>> 
>> While the first item in each section is the most important, I then list
>> later items in groups that have similar characteristics, which I think
>> simplifies reading.  While I could order all items in importance order,
>> I think it would be much more confusing to read.  Right now the item you
>> mention is in a group of items about optimizer statistics.
> 
> Actually, if there is no "most important" item in a section, I just
> order by placing the largest group of similar items first.  Here are the
> detais:
> 
> https://wiki.postgresql.org/wiki/Creating_Major_Release_Notes
> order inside of sections
>               most important item first in section
>                  if none, then largest group first
>               group similar items together
>               order group by item importance
>               ideally the last item in a group will relate to the first item in the next group
> 
> -- 
>  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
>  EDB                                      https://enterprisedb.com
> 
>  Do not let urgent matters crowd out time for investment in the future.
> 
> 

Hi Bruce,

This feature has been reverted by a0354e29c41a9fb7491b3c7c23f079b1923c045a.

```
<!--
Author: Andrew Dunstan <andrew@dunslane.net>
2026-03-12 [a0b6ef29a] Enable fast default for domains with non-volatile constr
-->

<listitem>
<para>
Allow the <link linkend="sql-altertable">addition of columns</link> based on domains containing constraints to usually avoid a table rewrite (Jian He)
<ulink url="&commit_baseurl;a0b6ef29a">&sect;</ulink>
</para>

<para>
Previously this always required a table rewrite.
</para>
</listitem>
```

So this item can be removed from the release note.

Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/









^ permalink  raw  reply  [nested|flat] 129+ messages in thread

* Re: First draft of PG 19 release notes
@ 2026-06-11 09:01  Srinath Reddy Sadipiralla <srinath2133@gmail.com>
  parent: Bruce Momjian <bruce@momjian.us>
  25 siblings, 1 reply; 129+ messages in thread

From: Srinath Reddy Sadipiralla @ 2026-06-11 09:01 UTC (permalink / raw)
  To: Bruce Momjian <bruce@momjian.us>; +Cc: PostgreSQL-development <pgsql-hackers@lists.postgresql.org>

Hi Bruce,

On Wed, Apr 15, 2026 at 6:49 AM Bruce Momjian <bruce@momjian.us> wrote:

> I have completed the first draft of the PG 19 release notes:
>
>         https://www.postgresql.org/docs/devel/release-19.html


Thanks for working on this.

I noticed the notes don't mention the pg_rewind improvement committed in
5173bfd0 ("pg_rewind: Skip copy of WAL segments generated before point of
divergence") [0].

[0] -
https://www.postgresql.org/message-id/flat/181b4c6fa9c.b8b725681941212.7547232617810891479%40viggy28...

-- 
Thanks :)
Srinath Reddy Sadipiralla
EDB: https://www.enterprisedb.com/

^ permalink  raw  reply  [nested|flat] 129+ messages in thread

* Re: First draft of PG 19 release notes
@ 2026-06-16 18:14  Bruce Momjian <bruce@momjian.us>
  parent: Chao Li <li.evan.chao@gmail.com>
  0 siblings, 0 replies; 129+ messages in thread

From: Bruce Momjian @ 2026-06-16 18:14 UTC (permalink / raw)
  To: Chao Li <li.evan.chao@gmail.com>; +Cc: PostgreSQL-development <pgsql-hackers@lists.postgresql.org>

On Tue, Jun  9, 2026 at 02:59:17PM +0800, Chao Li wrote:
> This feature has been reverted by a0354e29c41a9fb7491b3c7c23f079b1923c045a.
> 
> ```
> <!--
> Author: Andrew Dunstan <andrew@dunslane.net>
> 2026-03-12 [a0b6ef29a] Enable fast default for domains with non-volatile constr
> -->
> 
> <listitem>
> <para>
> Allow the <link linkend="sql-altertable">addition of columns</link> based on domains containing constraints to usually avoid a table rewrite (Jian He)
> <ulink url="&commit_baseurl;a0b6ef29a">&sect;</ulink>
> </para>
> 
> <para>
> Previously this always required a table rewrite.
> </para>
> </listitem>
> ```
> 
> So this item can be removed from the release note.

Thanks.  Reading the revert commit message, I am not sure I would have
associated it with this release note item's visible text.  Thanks.  I
updated the release notes to current.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Do not let urgent matters crowd out time for investment in the future.





^ permalink  raw  reply  [nested|flat] 129+ messages in thread

* Re: First draft of PG 19 release notes
@ 2026-06-16 23:41  Bruce Momjian <bruce@momjian.us>
  parent: Srinath Reddy Sadipiralla <srinath2133@gmail.com>
  0 siblings, 0 replies; 129+ messages in thread

From: Bruce Momjian @ 2026-06-16 23:41 UTC (permalink / raw)
  To: Srinath Reddy Sadipiralla <srinath2133@gmail.com>; +Cc: PostgreSQL-development <pgsql-hackers@lists.postgresql.org>

On Thu, Jun 11, 2026 at 02:31:38PM +0530, Srinath Reddy Sadipiralla wrote:
> Hi Bruce,
> 
> On Wed, Apr 15, 2026 at 6:49 AM Bruce Momjian <bruce@momjian.us> wrote:
> 
>     I have completed the first draft of the PG 19 release notes:
> 
>             https://www.postgresql.org/docs/devel/release-19.html
> 
> 
> Thanks for working on this.
> 
> I noticed the notes don't mention the pg_rewind improvement committed in
> 5173bfd0 ("pg_rewind: Skip copy of WAL segments generated before point of
> divergence") [0].
> 
> [0] - https://www.postgresql.org/message-id/flat/
> 181b4c6fa9c.b8b725681941212.7547232617810891479%40viggy28.dev

True.  In reading the commit message, it seems like a minor improvement
that wasn't worth mentioning;   it says:

	This commit makes the way WAL segments are handled from the source
	to the target server slightly smarter:
	                     ----------------

and

	This change can make the rewind operation cheaper in some
	configurations, especially for setups where some WAL retention
	causes many segments to remain on the source server even after the
	promotion of a standby used as source to rewind a previous primary.

It seemed like a nice improvement, but not something that would be
useful for the average user to know.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Do not let urgent matters crowd out time for investment in the future.





^ permalink  raw  reply  [nested|flat] 129+ messages in thread

* Re: First draft of PG 19 release notes
@ 2026-06-18 01:29  Fujii Masao <masao.fujii@gmail.com>
  parent: Bruce Momjian <bruce@momjian.us>
  25 siblings, 1 reply; 129+ messages in thread

From: Fujii Masao @ 2026-06-18 01:29 UTC (permalink / raw)
  To: Bruce Momjian <bruce@momjian.us>; +Cc: PostgreSQL-development <pgsql-hackers@lists.postgresql.org>

On Wed, Apr 15, 2026 at 10:19 AM Bruce Momjian <bruce@momjian.us> wrote:
>
> I have completed the first draft of the PG 19 release notes:

Thanks for working on the release note!

    Reduce lock level of ALTER DOMAIN ... VALIDATE CONSTRAINT to match
ALTER TABLE ... VALIDATE CONSTRAINT (Jian He) §

I reverted this change at commit 64797ad97d6, so could you please
remove this item from the release notes?

Regards,

-- 
Fujii Masao





^ permalink  raw  reply  [nested|flat] 129+ messages in thread

* Re: First draft of PG 19 release notes
@ 2026-06-18 01:34  Bruce Momjian <bruce@momjian.us>
  parent: Fujii Masao <masao.fujii@gmail.com>
  0 siblings, 1 reply; 129+ messages in thread

From: Bruce Momjian @ 2026-06-18 01:34 UTC (permalink / raw)
  To: Fujii Masao <masao.fujii@gmail.com>; +Cc: PostgreSQL-development <pgsql-hackers@lists.postgresql.org>

On Thu, Jun 18, 2026 at 10:29:47AM +0900, Fujii Masao wrote:
> On Wed, Apr 15, 2026 at 10:19 AM Bruce Momjian <bruce@momjian.us> wrote:
> >
> > I have completed the first draft of the PG 19 release notes:
> 
> Thanks for working on the release note!
> 
>     Reduce lock level of ALTER DOMAIN ... VALIDATE CONSTRAINT to match
> ALTER TABLE ... VALIDATE CONSTRAINT (Jian He) §
> 
> I reverted this change at commit 64797ad97d6, so could you please
> remove this item from the release notes?

Oh, I missed that one, removed, thanks.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Do not let urgent matters crowd out time for investment in the future.





^ permalink  raw  reply  [nested|flat] 129+ messages in thread

* Re: First draft of PG 19 release notes
@ 2026-06-18 01:45  Bruce Momjian <bruce@momjian.us>
  parent: Bruce Momjian <bruce@momjian.us>
  0 siblings, 1 reply; 129+ messages in thread

From: Bruce Momjian @ 2026-06-18 01:45 UTC (permalink / raw)
  To: Fujii Masao <masao.fujii@gmail.com>; +Cc: PostgreSQL-development <pgsql-hackers@lists.postgresql.org>

On Wed, Jun 17, 2026 at 09:34:38PM -0400, Bruce Momjian wrote:
> On Thu, Jun 18, 2026 at 10:29:47AM +0900, Fujii Masao wrote:
> > On Wed, Apr 15, 2026 at 10:19 AM Bruce Momjian <bruce@momjian.us> wrote:
> > >
> > > I have completed the first draft of the PG 19 release notes:
> > 
> > Thanks for working on the release note!
> > 
> >     Reduce lock level of ALTER DOMAIN ... VALIDATE CONSTRAINT to match
> > ALTER TABLE ... VALIDATE CONSTRAINT (Jian He) §
> > 
> > I reverted this change at commit 64797ad97d6, so could you please
> > remove this item from the release notes?
> 
> Oh, I missed that one, removed, thanks.

Ah, I missed it because it happened today and I was only current as of
yesterday.  I have now updated to be current as of today.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Do not let urgent matters crowd out time for investment in the future.





^ permalink  raw  reply  [nested|flat] 129+ messages in thread

* Re: First draft of PG 19 release notes
@ 2026-06-25 02:57  Chao Li <li.evan.chao@gmail.com>
  parent: Bruce Momjian <bruce@momjian.us>
  0 siblings, 1 reply; 129+ messages in thread

From: Chao Li @ 2026-06-25 02:57 UTC (permalink / raw)
  To: Bruce Momjian <bruce@momjian.us>; +Cc: PostgreSQL-development <pgsql-hackers@lists.postgresql.org>



> On Jun 18, 2026, at 09:45, Bruce Momjian <bruce@momjian.us> wrote:
> 
> On Wed, Jun 17, 2026 at 09:34:38PM -0400, Bruce Momjian wrote:
>> On Thu, Jun 18, 2026 at 10:29:47AM +0900, Fujii Masao wrote:
>>> On Wed, Apr 15, 2026 at 10:19 AM Bruce Momjian <bruce@momjian.us> wrote:
>>>> 
>>>> I have completed the first draft of the PG 19 release notes:
>>> 
>>> Thanks for working on the release note!
>>> 
>>>    Reduce lock level of ALTER DOMAIN ... VALIDATE CONSTRAINT to match
>>> ALTER TABLE ... VALIDATE CONSTRAINT (Jian He) §
>>> 
>>> I reverted this change at commit 64797ad97d6, so could you please
>>> remove this item from the release notes?
>> 
>> Oh, I missed that one, removed, thanks.
> 
> Ah, I missed it because it happened today and I was only current as of
> yesterday.  I have now updated to be current as of today.
> 
> -- 
>  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
>  EDB                                      https://enterprisedb.com
> 
>  Do not let urgent matters crowd out time for investment in the future.

Hi, Bruce,

I noticed a typo in the item about “2026-03-27 [d7965d65f] Add rudimentary table prioritization to autovacuum”. The line is quite long, so I attached a diff file for your convenience.

Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/

Attachments:

  [application/octet-stream] fix-typo-about-d7965d65f.diff (1.4K, ../../6D50BAF9-0586-420C-AFAC-CCDB61EF694A@gmail.com/2-fix-typo-about-d7965d65f.diff)
  download | inline diff:
diff --git a/doc/src/sgml/release-19.sgml b/doc/src/sgml/release-19.sgml
index 96a09d6cd6e..6f7ec4c22ac 100644
--- a/doc/src/sgml/release-19.sgml
+++ b/doc/src/sgml/release-19.sgml
@@ -1318,7 +1318,7 @@ Add scoring system to control the order that tables are processed by <link linke
 </para>
 
 <para>
-The new server variables are <link linkend="guc-autovacuum-freeze-score-weight"><varname>autovacuum_freeze_score_weight</varname></link>, <link linkend="guc-autovacuum-multixact-freeze-score-weight"><varname>autovacuum_multixact_freeze_score_weight</varname></link>, <link linkend="guc-autovacuum-vacuum-score-weight"><varname>autovacuum_vacuum_score_weight</varname></link>, <link linkend="guc-autovacuum-vacuum-insert-score-weight"><varname>vacuum_insert_score_weight</varname></link>, and
+The new server variables are <link linkend="guc-autovacuum-freeze-score-weight"><varname>autovacuum_freeze_score_weight</varname></link>, <link linkend="guc-autovacuum-multixact-freeze-score-weight"><varname>autovacuum_multixact_freeze_score_weight</varname></link>, <link linkend="guc-autovacuum-vacuum-score-weight"><varname>autovacuum_vacuum_score_weight</varname></link>, <link linkend="guc-autovacuum-vacuum-insert-score-weight"><varname>autovacuum_vacuum_insert_score_weight</varname></link>, and
 <link linkend="guc-autovacuum-analyze-score-weight"><varname>autovacuum_analyze_score_weight</varname></link>.
 </para>
 </listitem>

^ permalink  raw  reply  [nested|flat] 129+ messages in thread

* Re: First draft of PG 19 release notes
@ 2026-06-29 21:39  Bruce Momjian <bruce@momjian.us>
  parent: Chao Li <li.evan.chao@gmail.com>
  0 siblings, 0 replies; 129+ messages in thread

From: Bruce Momjian @ 2026-06-29 21:39 UTC (permalink / raw)
  To: Chao Li <li.evan.chao@gmail.com>; +Cc: PostgreSQL-development <pgsql-hackers@lists.postgresql.org>

On Thu, Jun 25, 2026 at 10:57:47AM +0800, Chao Li wrote:
> 
> 
> > On Jun 18, 2026, at 09:45, Bruce Momjian <bruce@momjian.us> wrote:
> > 
> > On Wed, Jun 17, 2026 at 09:34:38PM -0400, Bruce Momjian wrote:
> >> On Thu, Jun 18, 2026 at 10:29:47AM +0900, Fujii Masao wrote:
> >>> On Wed, Apr 15, 2026 at 10:19 AM Bruce Momjian <bruce@momjian.us> wrote:
> >>>> 
> >>>> I have completed the first draft of the PG 19 release notes:
> >>> 
> >>> Thanks for working on the release note!
> >>> 
> >>>    Reduce lock level of ALTER DOMAIN ... VALIDATE CONSTRAINT to match
> >>> ALTER TABLE ... VALIDATE CONSTRAINT (Jian He) §
> >>> 
> >>> I reverted this change at commit 64797ad97d6, so could you please
> >>> remove this item from the release notes?
> >> 
> >> Oh, I missed that one, removed, thanks.
> > 
> > Ah, I missed it because it happened today and I was only current as of
> > yesterday.  I have now updated to be current as of today.

Ah, I missed adding the "autovacuum_" prefix, committed.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Do not let urgent matters crowd out time for investment in the future.





^ permalink  raw  reply  [nested|flat] 129+ messages in thread

* Re: First draft of PG 19 release notes
@ 2026-07-02 22:12  Andreas Karlsson <andreas@proxel.se>
  parent: Bruce Momjian <bruce@momjian.us>
  25 siblings, 2 replies; 129+ messages in thread

From: Andreas Karlsson @ 2026-07-02 22:12 UTC (permalink / raw)
  To: Bruce Momjian <bruce@momjian.us>; PostgreSQL-development <pgsql-hackers@lists.postgresql.org>; +Cc: Jacob Champion <jacob.champion@enterprisedb.com>

Hi,

I noticed that some of the OAuth-realted items ended up under the wrong 
sections. See my suggestions below and the attached patch.

Jacob, do you have any opinion here?

= Add a new OAUTH flow hook PQAUTHDATA_OAUTH_BEARER_TOKEN_V2

Should go under "libpq"

= Allow custom OAUTH validators to register custom pg_hba.conf 
authentication options

Should go under "Server Configuration". It could arguably go under 
"Source Code" too but that seems less useful to the reader.

= Allow OAUTH validators to supply failure details

Should go under "Source Code" as this is not user facing.

--
Andreas Karlsson
Percona

Attachments:

  [text/x-patch] v1-0001-Move-some-OAuth-related-release-note-items-to-the.patch (4.0K, ../../061be328-b319-402a-b2a2-cdb99f85b2c1@proxel.se/2-v1-0001-Move-some-OAuth-related-release-note-items-to-the.patch)
  download | inline diff:
From 73684c2832cd652fd055924ff0f3199862714efb Mon Sep 17 00:00:00 2001
From: Andreas Karlsson <andreas@proxel.se>
Date: Fri, 3 Jul 2026 00:01:11 +0200
Subject: [PATCH v1] Move some OAuth related release note items to the right
 section

The two validator items belong under Server Configuration and Source
Code respectively and the one about PQAUTHDATA_OAUTH_BEARER_TOKEN_V2
belongs to libpq.
---
 doc/src/sgml/release-19.sgml | 42 ++++++++++++++++++------------------
 1 file changed, 21 insertions(+), 21 deletions(-)

diff --git a/doc/src/sgml/release-19.sgml b/doc/src/sgml/release-19.sgml
index d8d3758d5ba..194aee056e3 100644
--- a/doc/src/sgml/release-19.sgml
+++ b/doc/src/sgml/release-19.sgml
@@ -1341,20 +1341,29 @@ New configuration file <link linkend="guc-hosts-file"><filename>PGDATA/pg_hosts.
 
 <!--
 Author: Jacob Champion <jchampion@postgresql.org>
-2026-03-06 [e982331b5] libpq: Introduce PQAUTHDATA_OAUTH_BEARER_TOKEN_V2
+2026-04-07 [b977bd308] oauth: Allow validators to register custom HBA options
+-->
+
+<listitem>
+<para>
+Allow custom <acronym>OAUTH</acronym> validators to register custom <link linkend="auth-pg-hba-conf"><filename>pg_hba.conf</filename></link> authentication options (Jacob Champion)
+<ulink url="&commit_baseurl;b977bd308">&sect;</ulink>
+</para>
+</listitem>
+
+<!--
 Author: Jacob Champion <jchampion@postgresql.org>
-2026-03-31 [0af4d402c] libpq: Poison the v2 part of a v1 Bearer request
+2026-04-03 [d438a3659] oauth: Let validators provide failure DETAILs
 -->
 
 <listitem>
 <para>
-Add a new <acronym>OAUTH</acronym> flow hook <link linkend="libpq-oauth-authdata-oauth-bearer-token-v2"><literal>PQAUTHDATA_OAUTH_BEARER_TOKEN_V2</literal></link> (Jacob Champion)
-<ulink url="&commit_baseurl;e982331b5">&sect;</ulink>
-<ulink url="&commit_baseurl;0af4d402c">&sect;</ulink>
+Allow <acronym>OAUTH</acronym> validators to supply failure details (Jacob Champion)
+<ulink url="&commit_baseurl;d438a3659">&sect;</ulink>
 </para>
 
 <para>
-This is an improved version of <link linkend="libpq-oauth-authdata-oauth-bearer-token"><literal>PQAUTHDATA_OAUTH_BEARER_TOKEN</literal></link> by adding the issuer identifier and error message specification.
+This is done by setting the <link linkend="oauth-validator-callback-validate"><structname>ValidatorModuleResult</structname></link> structure member error_detail.
 </para>
 </listitem>
 
@@ -2355,29 +2364,20 @@ This can also be set via the <link linkend="libpq-envars"><envar>PGOAUTHCAFILE</
 
 <!--
 Author: Jacob Champion <jchampion@postgresql.org>
-2026-04-07 [b977bd308] oauth: Allow validators to register custom HBA options
--->
-
-<listitem>
-<para>
-Allow custom <acronym>OAUTH</acronym> validators to register custom <link linkend="auth-pg-hba-conf"><filename>pg_hba.conf</filename></link> authentication options (Jacob Champion)
-<ulink url="&commit_baseurl;b977bd308">&sect;</ulink>
-</para>
-</listitem>
-
-<!--
+2026-03-06 [e982331b5] libpq: Introduce PQAUTHDATA_OAUTH_BEARER_TOKEN_V2
 Author: Jacob Champion <jchampion@postgresql.org>
-2026-04-03 [d438a3659] oauth: Let validators provide failure DETAILs
+2026-03-31 [0af4d402c] libpq: Poison the v2 part of a v1 Bearer request
 -->
 
 <listitem>
 <para>
-Allow <acronym>OAUTH</acronym> validators to supply failure details (Jacob Champion)
-<ulink url="&commit_baseurl;d438a3659">&sect;</ulink>
+Add a new <acronym>OAUTH</acronym> flow hook <link linkend="libpq-oauth-authdata-oauth-bearer-token-v2"><literal>PQAUTHDATA_OAUTH_BEARER_TOKEN_V2</literal></link> (Jacob Champion)
+<ulink url="&commit_baseurl;e982331b5">&sect;</ulink>
+<ulink url="&commit_baseurl;0af4d402c">&sect;</ulink>
 </para>
 
 <para>
-This is done by setting the <link linkend="oauth-validator-callback-validate"><structname>ValidatorModuleResult</structname></link> structure member error_detail.
+This is an improved version of <link linkend="libpq-oauth-authdata-oauth-bearer-token"><literal>PQAUTHDATA_OAUTH_BEARER_TOKEN</literal></link> by adding the issuer identifier and error message specification.
 </para>
 </listitem>
 
-- 
2.43.0



^ permalink  raw  reply  [nested|flat] 129+ messages in thread

* Re: First draft of PG 19 release notes
@ 2026-07-02 22:16  Andreas Karlsson <andreas@proxel.se>
  parent: Andreas Karlsson <andreas@proxel.se>
  1 sibling, 1 reply; 129+ messages in thread

From: Andreas Karlsson @ 2026-07-02 22:16 UTC (permalink / raw)
  To: Bruce Momjian <bruce@momjian.us>; PostgreSQL-development <pgsql-hackers@lists.postgresql.org>; +Cc: Jacob Champion <jacob.champion@enterprisedb.com>

On 7/3/26 00:12, Andreas Karlsson wrote:
> I noticed that some of the OAuth-realted items ended up under the wrong 
> sections. See my suggestions below and the attached patch.
Ops, right patch attached now.

--
Andreas Karlsson
Percona

Attachments:

  [text/x-patch] v2-0001-Move-some-OAuth-related-release-note-items-to-the.patch (4.4K, ../../f5f129c3-88fa-43dc-a23a-75155fa10be3@proxel.se/2-v2-0001-Move-some-OAuth-related-release-note-items-to-the.patch)
  download | inline diff:
From ee68aa7653f2e7a0d31ec49684b66a8b9275e5d9 Mon Sep 17 00:00:00 2001
From: Andreas Karlsson <andreas@proxel.se>
Date: Fri, 3 Jul 2026 00:01:11 +0200
Subject: [PATCH v2] Move some OAuth related release note items to the right
 section

The two validator items belong under Server Configuration and Source
Code respectively and the one about PQAUTHDATA_OAUTH_BEARER_TOKEN_V2
belongs to libpq.
---
 doc/src/sgml/release-19.sgml | 44 ++++++++++++++++++------------------
 1 file changed, 22 insertions(+), 22 deletions(-)

diff --git a/doc/src/sgml/release-19.sgml b/doc/src/sgml/release-19.sgml
index d8d3758d5ba..5bb4c2ce15d 100644
--- a/doc/src/sgml/release-19.sgml
+++ b/doc/src/sgml/release-19.sgml
@@ -1341,20 +1341,18 @@ New configuration file <link linkend="guc-hosts-file"><filename>PGDATA/pg_hosts.
 
 <!--
 Author: Jacob Champion <jchampion@postgresql.org>
-2026-03-06 [e982331b5] libpq: Introduce PQAUTHDATA_OAUTH_BEARER_TOKEN_V2
-Author: Jacob Champion <jchampion@postgresql.org>
-2026-03-31 [0af4d402c] libpq: Poison the v2 part of a v1 Bearer request
+2026-04-07 [b977bd308] oauth: Allow validators to register custom HBA options
 -->
 
 <listitem>
 <para>
-Add a new <acronym>OAUTH</acronym> flow hook <link linkend="libpq-oauth-authdata-oauth-bearer-token-v2"><literal>PQAUTHDATA_OAUTH_BEARER_TOKEN_V2</literal></link> (Jacob Champion)
-<ulink url="&commit_baseurl;e982331b5">&sect;</ulink>
-<ulink url="&commit_baseurl;0af4d402c">&sect;</ulink>
+Allow custom <acronym>OAUTH</acronym> validators to register custom <link linkend="auth-pg-hba-conf"><filename>pg_hba.conf</filename></link> authentication options (Jacob Champion)
+<ulink url="&commit_baseurl;b977bd308">&sect;</ulink>
 </para>
+</listitem>
 
 <para>
-This is an improved version of <link linkend="libpq-oauth-authdata-oauth-bearer-token"><literal>PQAUTHDATA_OAUTH_BEARER_TOKEN</literal></link> by adding the issuer identifier and error message specification.
+This is done by setting the <link linkend="oauth-validator-callback-validate"><structname>ValidatorModuleResult</structname></link> structure member error_detail.
 </para>
 </listitem>
 
@@ -2355,29 +2353,20 @@ This can also be set via the <link linkend="libpq-envars"><envar>PGOAUTHCAFILE</
 
 <!--
 Author: Jacob Champion <jchampion@postgresql.org>
-2026-04-07 [b977bd308] oauth: Allow validators to register custom HBA options
--->
-
-<listitem>
-<para>
-Allow custom <acronym>OAUTH</acronym> validators to register custom <link linkend="auth-pg-hba-conf"><filename>pg_hba.conf</filename></link> authentication options (Jacob Champion)
-<ulink url="&commit_baseurl;b977bd308">&sect;</ulink>
-</para>
-</listitem>
-
-<!--
+2026-03-06 [e982331b5] libpq: Introduce PQAUTHDATA_OAUTH_BEARER_TOKEN_V2
 Author: Jacob Champion <jchampion@postgresql.org>
-2026-04-03 [d438a3659] oauth: Let validators provide failure DETAILs
+2026-03-31 [0af4d402c] libpq: Poison the v2 part of a v1 Bearer request
 -->
 
 <listitem>
 <para>
-Allow <acronym>OAUTH</acronym> validators to supply failure details (Jacob Champion)
-<ulink url="&commit_baseurl;d438a3659">&sect;</ulink>
+Add a new <acronym>OAUTH</acronym> flow hook <link linkend="libpq-oauth-authdata-oauth-bearer-token-v2"><literal>PQAUTHDATA_OAUTH_BEARER_TOKEN_V2</literal></link> (Jacob Champion)
+<ulink url="&commit_baseurl;e982331b5">&sect;</ulink>
+<ulink url="&commit_baseurl;0af4d402c">&sect;</ulink>
 </para>
 
 <para>
-This is done by setting the <link linkend="oauth-validator-callback-validate"><structname>ValidatorModuleResult</structname></link> structure member error_detail.
+This is an improved version of <link linkend="libpq-oauth-authdata-oauth-bearer-token"><literal>PQAUTHDATA_OAUTH_BEARER_TOKEN</literal></link> by adding the issuer identifier and error message specification.
 </para>
 </listitem>
 
@@ -3016,6 +3005,17 @@ Author: Heikki Linnakangas <heikki.linnakangas@iki.fi>
 2026-04-06 [283e823f9] Introduce a new mechanism for registering shared memory
 -->
 
+<!--
+Author: Jacob Champion <jchampion@postgresql.org>
+2026-04-03 [d438a3659] oauth: Let validators provide failure DETAILs
+-->
+
+<listitem>
+<para>
+Allow <acronym>OAUTH</acronym> validators to supply failure details (Jacob Champion)
+<ulink url="&commit_baseurl;d438a3659">&sect;</ulink>
+</para>
+
 <listitem>
 <para>
 Add simplified and improved shared memory registration function <link linkend="xfunc-shared-addin-at-startup"><function>ShmemRequestStruct()</function></link> (Heikki Linnakangas, Ashutosh Bapat)
-- 
2.43.0



^ permalink  raw  reply  [nested|flat] 129+ messages in thread

* Re: First draft of PG 19 release notes
@ 2026-07-02 22:35  Jacob Champion <jacob.champion@enterprisedb.com>
  parent: Andreas Karlsson <andreas@proxel.se>
  1 sibling, 0 replies; 129+ messages in thread

From: Jacob Champion @ 2026-07-02 22:35 UTC (permalink / raw)
  To: Andreas Karlsson <andreas@proxel.se>; +Cc: Bruce Momjian <bruce@momjian.us>; PostgreSQL-development <pgsql-hackers@lists.postgresql.org>

On Thu, Jul 2, 2026 at 3:12 PM Andreas Karlsson <andreas@proxel.se> wrote:
> Jacob, do you have any opinion here?

I've got a TODO to edit the feature docs that I haven't been able to
check off yet. But no objections to your proposed moves at the moment
(they might need to move again when I really sit down and stare at
them).

Thanks!
--Jacob






^ permalink  raw  reply  [nested|flat] 129+ messages in thread

* Re: First draft of PG 19 release notes
@ 2026-07-15 09:56  Bruce Momjian <bruce@momjian.us>
  parent: Andreas Karlsson <andreas@proxel.se>
  0 siblings, 1 reply; 129+ messages in thread

From: Bruce Momjian @ 2026-07-15 09:56 UTC (permalink / raw)
  To: Andreas Karlsson <andreas@proxel.se>; +Cc: PostgreSQL-development <pgsql-hackers@lists.postgresql.org>; Jacob Champion <jacob.champion@enterprisedb.com>

On Fri, Jul  3, 2026 at 12:16:05AM +0200, Andreas Karlsson wrote:
> On 7/3/26 00:12, Andreas Karlsson wrote:
> > I noticed that some of the OAuth-realted items ended up under the wrong
> > sections. See my suggestions below and the attached patch.
> Ops, right patch attached now.

Changes applied;  sorry for the delay. I had to create a new patch
because the submitted patch had invalid markup, moved the first
paragraph of items but left the second paragraph alone, and I didn't
like the order of the error_detail item.  I ended up moving the error
detail item to Source Code, and swapped the validator and hook items.  

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Do not let urgent matters crowd out time for investment in the future.






^ permalink  raw  reply  [nested|flat] 129+ messages in thread

* Re: First draft of PG 19 release notes
@ 2026-07-15 21:55  Bruce Momjian <bruce@momjian.us>
  parent: Bruce Momjian <bruce@momjian.us>
  0 siblings, 1 reply; 129+ messages in thread

From: Bruce Momjian @ 2026-07-15 21:55 UTC (permalink / raw)
  To: Andreas Karlsson <andreas@proxel.se>; +Cc: PostgreSQL-development <pgsql-hackers@lists.postgresql.org>; Jacob Champion <jacob.champion@enterprisedb.com>

On Wed, Jul 15, 2026 at 05:56:07AM -0400, Bruce Momjian wrote:
> On Fri, Jul  3, 2026 at 12:16:05AM +0200, Andreas Karlsson wrote:
> > On 7/3/26 00:12, Andreas Karlsson wrote:
> > > I noticed that some of the OAuth-realted items ended up under the wrong
> > > sections. See my suggestions below and the attached patch.
> > Ops, right patch attached now.
> 
> Changes applied;  sorry for the delay. I had to create a new patch
> because the submitted patch had invalid markup, moved the first
> paragraph of items but left the second paragraph alone, and I didn't
> like the order of the error_detail item.  I ended up moving the error
> detail item to Source Code, and swapped the validator and hook items.  

You can see the updated output here:

	https://momjian.us/pgsql_docs/release-19.html

Let me know if there should be anymore changes?

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Do not let urgent matters crowd out time for investment in the future.






^ permalink  raw  reply  [nested|flat] 129+ messages in thread

* Re: First draft of PG 19 release notes
@ 2026-07-16 20:38  Jacob Champion <jacob.champion@enterprisedb.com>
  parent: Bruce Momjian <bruce@momjian.us>
  0 siblings, 1 reply; 129+ messages in thread

From: Jacob Champion @ 2026-07-16 20:38 UTC (permalink / raw)
  To: Bruce Momjian <bruce@momjian.us>; +Cc: Andreas Karlsson <andreas@proxel.se>; PostgreSQL-development <pgsql-hackers@lists.postgresql.org>

On Wed, Jul 15, 2026 at 2:57 PM Bruce Momjian <bruce@momjian.us> wrote:
> You can see the updated output here:
>
>         https://momjian.us/pgsql_docs/release-19.html

Thanks! I think one of those patches partially undid the other one; see below.

> Let me know if there should be anymore changes?

I've definitely kept you waiting long enough. See attached suggestions
for my entries.

First patch adjusts credit, expands/rewords some items [1], and
rewrites the new authdata hook section to hopefully better illustrate
why it belongs to libpq. Let me know what you think.

Second patch should just be motion, I hope: the pg_hba changes go into
the server config section and the authdata hook goes into libpq. It
also deprioritizes the PQgetThreadLock() section, which I imagine very
few people will care about in practice. :D

I think this replays some of what Andreas was hoping for, maybe with
more context. I'm not sure why "Allow OAuth validators to supply
failure details" is still with server configuration at the moment,
based on the conversation above, so maybe that also needs to be moved
back to Source Code. I didn't do that here, in case it was on purpose.

(I don't know if it's been discussed somewhere, but I find that the
standard Git diff algorithm can't handle these sorts of doc-motion
patches in a readable way. The attached patches were generated with
`git format-patch --histogram` instead.)

Thanks,
--Jacob

[1] "OAuth" is the overall feature, `oauth` is the HBA method name,
and `OAUTHBEARER` is the developer-facing SASL mechanism name.
Unfortunately (or fortunately?) none of them are acronyms. This is
kind of analogous to the distinction we'd have to make between
"Kerberos", `gss`, and the `GSSAPI` SASL mech (if we used it).

Attachments:

  [application/octet-stream] 0001-19-release-docs-reword-expand-credit.patch (3.7K, ../../CAOYmi+k5h_w5p6HsVJF5k+bNGmChMAhpGU_1gjJMxHg080XibA@mail.gmail.com/2-0001-19-release-docs-reword-expand-credit.patch)
  download | inline diff:
From 3f9441a31df52da0241afec996a126c9192e9d5d Mon Sep 17 00:00:00 2001
From: Jacob Champion <jacob.champion@enterprisedb.com>
Date: Thu, 16 Jul 2026 12:28:43 -0700
Subject: [PATCH 1/2] 19 release docs: reword/expand/credit

---
 doc/src/sgml/release-19.sgml | 16 ++++++++++------
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/doc/src/sgml/release-19.sgml b/doc/src/sgml/release-19.sgml
index cc47c190c9c..39d8e4260b1 100644
--- a/doc/src/sgml/release-19.sgml
+++ b/doc/src/sgml/release-19.sgml
@@ -1346,7 +1346,7 @@ Author: Jacob Champion <jchampion@postgresql.org>
 
 <listitem>
 <para>
-Allow <acronym>OAUTH</acronym> validators to supply failure details (Jacob Champion)
+Allow OAuth validators to supply failure details (Jacob Champion)
 <ulink url="&commit_baseurl;d438a3659">&sect;</ulink>
 </para>
 
@@ -2317,9 +2317,13 @@ Author: Jacob Champion <jchampion@postgresql.org>
 
 <listitem>
 <para>
-Add special libpq protocol version 3.9999 for version testing (Jelte Fennema-Nio)
+Add special libpq protocol parameters for compatibility testing (Jelte Fennema-Nio, Jacob Champion)
 <ulink url="&commit_baseurl;d8d7c5dc8">&sect;</ulink>
 </para>
+
+<para>
+Otherwise known as <ulink url="https://wiki.postgresql.org/wiki/Grease">protocol grease</ulink>, which was active during the 19 beta period. These will no longer be sent as of the <productname>PostgreSQL</productname> 19 official release, but the parameter reservations will remain for potential use in the future.
+</para>
 </listitem>
 
 <!--
@@ -2341,7 +2345,7 @@ Author: Jacob Champion <jchampion@postgresql.org>
 
 <listitem>
 <para>
-Add libpq connection parameter <link linkend="libpq-connect-oauth-ca-file"><varname>oauth_ca_file</varname></link> to specify the <acronym>OAUTH</acronym> certificate authority file (Jonathan Gonzalez V., Jacob Champion)
+Add libpq connection parameter <link linkend="libpq-connect-oauth-ca-file"><varname>oauth_ca_file</varname></link> to specify an alternate certificate authority when communicating with OAuth providers (Jonathan Gonzalez V., Jacob Champion)
 <ulink url="&commit_baseurl;993368113">&sect;</ulink>
 </para>
 
@@ -2357,7 +2361,7 @@ Author: Jacob Champion <jchampion@postgresql.org>
 
 <listitem>
 <para>
-Allow <acronym>OAUTH</acronym> validators to register custom <link linkend="auth-pg-hba-conf"><filename>pg_hba.conf</filename></link> authentication options (Jacob Champion)
+Allow OAuth validators to register custom <link linkend="auth-pg-hba-conf"><filename>pg_hba.conf</filename></link> authentication options (Jacob Champion, Zsolt Parragi)
 <ulink url="&commit_baseurl;b977bd308">&sect;</ulink>
 </para>
 </listitem>
@@ -2965,13 +2969,13 @@ Author: Jacob Champion <jchampion@postgresql.org>
 
 <listitem>
 <para>
-Add a new <acronym>OAUTH</acronym> flow hook <link linkend="libpq-oauth-authdata-oauth-bearer-token-v2"><literal>PQAUTHDATA_OAUTH_BEARER_TOKEN_V2</literal></link> (Jacob Champion)
+Improve custom OAuth client flows (Jacob Champion)
 <ulink url="&commit_baseurl;e982331b5">&sect;</ulink>
 <ulink url="&commit_baseurl;0af4d402c">&sect;</ulink>
 </para>
 
 <para>
-This is an improved version of <link linkend="libpq-oauth-authdata-oauth-bearer-token"><literal>PQAUTHDATA_OAUTH_BEARER_TOKEN</literal></link> by adding the issuer identifier and error message specification.
+Previously, libpq reported only a generic error message during custom flow failures, and each flow implementation was required to calculate the issuer identifier independently. Add a new authdata hook type <link linkend="libpq-oauth-authdata-oauth-bearer-token-v2"><literal>PQAUTHDATA_OAUTH_BEARER_TOKEN_V2</literal></link> that precomputes the issuer ID and lets hooks provide error details.
 </para>
 </listitem>
 
-- 
2.34.1



  [application/octet-stream] 0002-19-release-docs-move-sections-around.patch (5.2K, ../../CAOYmi+k5h_w5p6HsVJF5k+bNGmChMAhpGU_1gjJMxHg080XibA@mail.gmail.com/3-0002-19-release-docs-move-sections-around.patch)
  download | inline diff:
From 65d8ec6f7c4eb25350ded5d14f5b24bea603ed19 Mon Sep 17 00:00:00 2001
From: Jacob Champion <jacob.champion@enterprisedb.com>
Date: Thu, 16 Jul 2026 12:28:43 -0700
Subject: [PATCH 2/2] 19 release docs: move sections around

- HBA options belong to the server
- custom OAuth client flows belong to libpq
- deprioritize PQgetThreadLock()
---
 doc/src/sgml/release-19.sgml | 86 ++++++++++++++++++------------------
 1 file changed, 43 insertions(+), 43 deletions(-)

diff --git a/doc/src/sgml/release-19.sgml b/doc/src/sgml/release-19.sgml
index 39d8e4260b1..7545f2332da 100644
--- a/doc/src/sgml/release-19.sgml
+++ b/doc/src/sgml/release-19.sgml
@@ -1339,6 +1339,18 @@ New configuration file <link linkend="guc-hosts-file"><filename>PGDATA/pg_hosts.
 </para>
 </listitem>
 
+<!--
+Author: Jacob Champion <jchampion@postgresql.org>
+2026-04-07 [b977bd308] oauth: Allow validators to register custom HBA options
+-->
+
+<listitem>
+<para>
+Allow OAuth validators to register custom <link linkend="auth-pg-hba-conf"><filename>pg_hba.conf</filename></link> authentication options (Jacob Champion, Zsolt Parragi)
+<ulink url="&commit_baseurl;b977bd308">&sect;</ulink>
+</para>
+</listitem>
+
 <!--
 Author: Jacob Champion <jchampion@postgresql.org>
 2026-04-03 [d438a3659] oauth: Let validators provide failure DETAILs
@@ -2326,18 +2338,6 @@ Otherwise known as <ulink url="https://wiki.postgresql.org/wiki/Grease">protocol
 </para>
 </listitem>
 
-<!--
-Author: Jacob Champion <jchampion@postgresql.org>
-2026-03-05 [b8d768583] libpq: Add PQgetThreadLock() to mirror PQregisterThreadL
--->
-
-<listitem>
-<para>
-Add libpq function <link linkend="libpq-threading"><function>PQgetThreadLock()</function></link> to retrieve the current locking callback (Jacob Champion)
-<ulink url="&commit_baseurl;b8d768583">&sect;</ulink>
-</para>
-</listitem>
-
 <!--
 Author: Jacob Champion <jchampion@postgresql.org>
 2026-03-30 [993368113] libpq: Add oauth_ca_file option to change CAs without de
@@ -2354,18 +2354,6 @@ This can also be set via the <link linkend="libpq-envars"><envar>PGOAUTHCAFILE</
 </para>
 </listitem>
 
-<!--
-Author: Jacob Champion <jchampion@postgresql.org>
-2026-04-07 [b977bd308] oauth: Allow validators to register custom HBA options
--->
-
-<listitem>
-<para>
-Allow OAuth validators to register custom <link linkend="auth-pg-hba-conf"><filename>pg_hba.conf</filename></link> authentication options (Jacob Champion, Zsolt Parragi)
-<ulink url="&commit_baseurl;b977bd308">&sect;</ulink>
-</para>
-</listitem>
-
 <!--
 Author: Jacob Champion <jchampion@postgresql.org>
 2026-04-07 [6d00fb904] libpq: Split PGOAUTHDEBUG=UNSAFE into multiple options
@@ -2380,6 +2368,37 @@ Allow libpq environment variable <link linkend="libpq-envars"><envar>PGOAUTHDEBU
 <para>
 The <literal>UNSAFE</literal> option still generates all debugging output.
 </para>
+</listitem>
+
+<!--
+Author: Jacob Champion <jchampion@postgresql.org>
+2026-03-06 [e982331b5] libpq: Introduce PQAUTHDATA_OAUTH_BEARER_TOKEN_V2
+Author: Jacob Champion <jchampion@postgresql.org>
+2026-03-31 [0af4d402c] libpq: Poison the v2 part of a v1 Bearer request
+-->
+
+<listitem>
+<para>
+Improve custom OAuth client flows (Jacob Champion)
+<ulink url="&commit_baseurl;e982331b5">&sect;</ulink>
+<ulink url="&commit_baseurl;0af4d402c">&sect;</ulink>
+</para>
+
+<para>
+Previously, libpq reported only a generic error message during custom flow failures, and each flow implementation was required to calculate the issuer identifier independently. Add a new authdata hook type <link linkend="libpq-oauth-authdata-oauth-bearer-token-v2"><literal>PQAUTHDATA_OAUTH_BEARER_TOKEN_V2</literal></link> that precomputes the issuer ID and lets hooks provide error details.
+</para>
+</listitem>
+
+<!--
+Author: Jacob Champion <jchampion@postgresql.org>
+2026-03-05 [b8d768583] libpq: Add PQgetThreadLock() to mirror PQregisterThreadL
+-->
+
+<listitem>
+<para>
+Add libpq function <link linkend="libpq-threading"><function>PQgetThreadLock()</function></link> to retrieve the current locking callback (Jacob Champion)
+<ulink url="&commit_baseurl;b8d768583">&sect;</ulink>
+</para>
 </listitem>
 
     </itemizedlist>
@@ -2960,25 +2979,6 @@ Allow extensions to replace <link linkend="xfunc-sql-functions-returning-set">se
 </para>
 </listitem>
 
-<!--
-Author: Jacob Champion <jchampion@postgresql.org>
-2026-03-06 [e982331b5] libpq: Introduce PQAUTHDATA_OAUTH_BEARER_TOKEN_V2
-Author: Jacob Champion <jchampion@postgresql.org>
-2026-03-31 [0af4d402c] libpq: Poison the v2 part of a v1 Bearer request
--->
-
-<listitem>
-<para>
-Improve custom OAuth client flows (Jacob Champion)
-<ulink url="&commit_baseurl;e982331b5">&sect;</ulink>
-<ulink url="&commit_baseurl;0af4d402c">&sect;</ulink>
-</para>
-
-<para>
-Previously, libpq reported only a generic error message during custom flow failures, and each flow implementation was required to calculate the issuer identifier independently. Add a new authdata hook type <link linkend="libpq-oauth-authdata-oauth-bearer-token-v2"><literal>PQAUTHDATA_OAUTH_BEARER_TOKEN_V2</literal></link> that precomputes the issuer ID and lets hooks provide error details.
-</para>
-</listitem>
-
 <!--
 Author: Heikki Linnakangas <heikki.linnakangas@iki.fi>
 2025-12-09 [bd8d9c9bd] Widen MultiXactOffset to 64 bits
-- 
2.34.1



^ permalink  raw  reply  [nested|flat] 129+ messages in thread

* Re: First draft of PG 19 release notes
@ 2026-07-17 20:04  Bruce Momjian <bruce@momjian.us>
  parent: Jacob Champion <jacob.champion@enterprisedb.com>
  0 siblings, 1 reply; 129+ messages in thread

From: Bruce Momjian @ 2026-07-17 20:04 UTC (permalink / raw)
  To: Jacob Champion <jacob.champion@enterprisedb.com>; +Cc: Andreas Karlsson <andreas@proxel.se>; PostgreSQL-development <pgsql-hackers@lists.postgresql.org>

On Thu, Jul 16, 2026 at 01:38:00PM -0700, Jacob Champion wrote:
> On Wed, Jul 15, 2026 at 2:57 PM Bruce Momjian <bruce@momjian.us> wrote:
> > You can see the updated output here:
> >
> >         https://momjian.us/pgsql_docs/release-19.html
> 
> Thanks! I think one of those patches partially undid the other one; see below.
> 
> > Let me know if there should be anymore changes?
> 
> I've definitely kept you waiting long enough. See attached suggestions
> for my entries.
> 
> First patch adjusts credit, expands/rewords some items [1], and
> rewrites the new authdata hook section to hopefully better illustrate
> why it belongs to libpq. Let me know what you think.
> 
> Second patch should just be motion, I hope: the pg_hba changes go into
> the server config section and the authdata hook goes into libpq. It
> also deprioritizes the PQgetThreadLock() section, which I imagine very
> few people will care about in practice. :D

Patch applied.

> I think this replays some of what Andreas was hoping for, maybe with
> more context. I'm not sure why "Allow OAuth validators to supply
> failure details" is still with server configuration at the moment,
> based on the conversation above, so maybe that also needs to be moved
> back to Source Code. I didn't do that here, in case it was on purpose.

I am confused by this item.  I moved it to Source Code in commit
aa9787e325d, but then moved it again in commit 0546889b1b9.  I have
moved it back to Source Code as you suggested.

> (I don't know if it's been discussed somewhere, but I find that the
> standard Git diff algorithm can't handle these sorts of doc-motion
> patches in a readable way. The attached patches were generated with
> `git format-patch --histogram` instead.)

I am very glad you mentioned this.  I have been traveling for two weeks,
and tried to get the original patch applied several times.  I would
study the patch, and the things wrong with the patch, and then get
confused.  I thought I was losing my ability to analyze patches or
something.  Combining the fact I don't understand how all the Oauth
features fit together with the problems of understanding a patch with no
context really overwhelmed me, plus I am trying to fit it into a travel
schedule.

The current output is at:

	https://momjian.us/pgsql_docs/release-19.html

Please let me know if there should be some more changes.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Do not let urgent matters crowd out time for investment in the future.






^ permalink  raw  reply  [nested|flat] 129+ messages in thread

* Re: First draft of PG 19 release notes
@ 2026-07-17 22:03  Chao Li <li.evan.chao@gmail.com>
  parent: Bruce Momjian <bruce@momjian.us>
  0 siblings, 1 reply; 129+ messages in thread

From: Chao Li @ 2026-07-17 22:03 UTC (permalink / raw)
  To: Bruce Momjian <bruce@momjian.us>; +Cc: PostgreSQL-development <pgsql-hackers@lists.postgresql.org>

Hi Bruce,

This feature has been reverted by 372b8d1adb76740123791e9ded4f665b175f5bf5, so you need to delete the item from the v19 release note. 

<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
2025-09-29 [ef38a4d97] Add GROUP BY ALL.
-->

Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/










^ permalink  raw  reply  [nested|flat] 129+ messages in thread

* Re: First draft of PG 19 release notes
@ 2026-07-19 00:50  Bruce Momjian <bruce@momjian.us>
  parent: Chao Li <li.evan.chao@gmail.com>
  0 siblings, 0 replies; 129+ messages in thread

From: Bruce Momjian @ 2026-07-19 00:50 UTC (permalink / raw)
  To: Chao Li <li.evan.chao@gmail.com>; +Cc: PostgreSQL-development <pgsql-hackers@lists.postgresql.org>

On Sat, Jul 18, 2026 at 06:03:09AM +0800, Chao Li wrote:
> Hi Bruce,
> 
> This feature has been reverted by 372b8d1adb76740123791e9ded4f665b175f5bf5, so you need to delete the item from the v19 release note. 
> 
> <!--
> Author: Tom Lane <tgl@sss.pgh.pa.us>
> 2025-09-29 [ef38a4d97] Add GROUP BY ALL.
> -->

I have updated the release notes to match current git;  updated output
is at:

	https://momjian.us/pgsql_docs/

Patch attached.  I added the psql \crosstabview item as an
incompatibility.  I didn't add this commit:

	commit 0c15b715c65
	Author: Tom Lane <tgl@sss.pgh.pa.us>
	Date:   Tue Jun 30 17:21:23 2026 -0400
	
	    Disallow set-returning functions within window OVER clauses.
	
	    We previously allowed this, but it leads to odd behaviors, basically
	    because putting a SRF there is inconsistent with the principle that a
	    window function doesn't change the number of rows in the query result.
	    There doesn't seem to be a strong reason to try to make such cases
	    behave consistently.  Users should put their SRFs in lateral FROM
	    clauses instead.
	
	    This issue has been sitting on the back burner for multiple years
	    now, partially because it didn't seem wise to back-patch such a
	    change.  Let's squeeze it into v19 before it's too late.

because I assumed its use was rare enough and the error message clear
enough.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Do not let urgent matters crowd out time for investment in the future.

Attachments:

  [text/x-diff] REL_19_STABLE.diff (3.5K, ../../alwfUMjJ8NADFEF9@momjian.us/2-REL_19_STABLE.diff)
  download | inline diff:
diff --git a/doc/src/sgml/release-19.sgml b/doc/src/sgml/release-19.sgml
index 75f0ea04fda..7e93f7a8b95 100644
--- a/doc/src/sgml/release-19.sgml
+++ b/doc/src/sgml/release-19.sgml
@@ -6,7 +6,7 @@
 
  <formalpara>
   <title>Release date:</title>
-  <para>2026-??-??, AS OF 2026-06-17</para>
+  <para>2026-??-??, AS OF 2026-07-18</para>
  </formalpara>
 
   <sect2 id="release-19-highlights">
@@ -307,6 +307,18 @@ Remove optimizer hook get_relation_info_hook and add better-placed hook build_si
 </para>
 </listitem>
 
+<!--
+Author: Álvaro Herrera <alvherre@kurilemu.de>
+2026-06-26 [4df5fe383] 2026-06-26 Make crosstabview honor boolean/null display
+-->
+
+<listitem>
+<para>
+Change <link linkend="app-psql"><application>psql</application></link>'s <literal>\crosstabview</literal> command to honor the <literal>\pset null</literal> setting (Chao Li)
+<ulink url="&commit_baseurl;4df5fe383">&sect;</ulink>
+</para>
+</listitem>
+
 <!--
 Author: Thomas Munro <tmunro@postgresql.org>
 2026-04-08 [77645d44e] Remove MULE_INTERNAL encoding.
@@ -1690,18 +1702,6 @@ This allows operations on temporal ranges.
 </para>
 </listitem>
 
-<!--
-Author: Tom Lane <tgl@sss.pgh.pa.us>
-2025-09-29 [ef38a4d97] Add GROUP BY ALL.
--->
-
-<listitem>
-<para>
-Add <literal>GROUP BY ALL</literal> syntax to <link linkend="sql-select"><command>SELECT</command></link> to automatically group all non-aggregate and non-window-function target list parameters (David Christensen)
-<ulink url="&commit_baseurl;ef38a4d97">&sect;</ulink>
-</para>
-</listitem>
-
 <!--
 Author: Tom Lane <tgl@sss.pgh.pa.us>
 2026-03-06 [415100aa6] Support grouping-expression references and GROUPING() in
@@ -2536,6 +2536,18 @@ Add or improve <link linkend="app-psql"><application>psql</application></link> t
     <title>Server Applications</title>
 
     <itemizedlist>
+<!--
+Author: Michael Paquier <michael@paquier.xyz>
+2026-01-27 [c32fb29e9] Include extended statistics data in pg_dump
+-->
+
+<listitem>
+<para>
+Allow <link linkend="app-pgdump"><application>pg_dump</application></link> to include restorable extended statistics (Corey Huinker)
+<ulink url="&commit_baseurl;c32fb29e9">&sect;</ulink>
+</para>
+</listitem>
+
 <!--
 Author: Fujii Masao <fujii@postgresql.org>
 2025-08-20 [6429e5b77] vacuumdb: Make vacuumdb - -analyze-only process partition
@@ -2665,33 +2677,10 @@ Improve the usability of <link linkend="pgtesttiming"><application>pg_test_timin
 <para>
 Report nanoseconds instead of microseconds.  In addition to histogram output, output a second table that reports exact timings, with an optional cutoff set by <option>--cutoff</option>.
 </para>
-</listitem>
-
-    </itemizedlist>
-
-    <sect4 id="release-19-pgdump">
-     <title><link
-     linkend="app-pgdump"><application>pg_dump</application></link>/<link
-     linkend="app-pg-dumpall"><application>pg_dumpall</application></link>/<link
-     linkend="app-pgrestore"><application>pg_restore</application></link></title>
-
-     <itemizedlist>
-<!--
-Author: Michael Paquier <michael@paquier.xyz>
-2026-01-27 [c32fb29e9] Include extended statistics data in pg_dump
--->
-
-<listitem>
-<para>
-Allow <link linkend="app-pgdump"><application>pg_dump</application></link> to include restorable extended statistics (Corey Huinker)
-<ulink url="&commit_baseurl;c32fb29e9">&sect;</ulink>
-</para>
 </listitem>
 
      </itemizedlist>
 
-    </sect4>
-
     <sect4 id="release-19-pg-createsubscriber">
      <title><link linkend="app-pgcreatesubscriber"><application>pg_createsubscriber</application></link></title>
 

^ permalink  raw  reply  [nested|flat] 129+ messages in thread

* Re: First draft of PG 19 release notes
@ 2026-08-14 10:04  Etsuro Fujita <etsuro.fujita@gmail.com>
  parent: Etsuro Fujita <etsuro.fujita@gmail.com>
  0 siblings, 1 reply; 129+ messages in thread

From: Etsuro Fujita @ 2026-08-14 10:04 UTC (permalink / raw)
  To: Bruce Momjian <bruce@momjian.us>; +Cc: PostgreSQL-development <pgsql-hackers@lists.postgresql.org>

On Sat, May 9, 2026 at 6:15 PM Etsuro Fujita <etsuro.fujita@gmail.com> wrote:
> On Fri, May 8, 2026 at 8:08 AM Bruce Momjian <bruce@momjian.us> wrote:
> > On Tue, Apr 21, 2026 at 05:24:59AM -0700, Etsuro Fujita wrote:
> > > "Allow the retrieval of statistics from foreign data wrapper servers
> > > (Corey Huinker, Etsuro Fujita)"
> > >
> > > This is mentioned in the Additional Modules section, presumably
> > > because it was supported in postgres_fdw, but it isn't limited to
> > > postgres_fdw, so we should move it to the General Performance section?
> >
> > Well, the full text is:
> >
> >         Allow the retrieval of statistics from foreign data wrapper servers
> >         (Corey Huinker, Etsuro Fujita) §
> >
> >         This is enabled for postgres_fdw by using the option restore_stats. The
> >         default is for ANALYZE to retrieve rows from the remote server to
> >         locally generate statistics.
> >
> > It clearly mentions in the detail that it applies only to postgres_fdw,
> > so I think it is already in the right section.  While it technically can
> > be done by any FDW, it is now only postgres_fdw so people looking for
> > postgres_fdw improvements will find it in the Additional Modules
> > section.  What we can do is to reword it to:
> >
> > -->     Allow the retrieval of statistics from postgres_fdw foreign data wrapper servers
> >         (Corey Huinker, Etsuro Fujita) §
> >
> > -->     This is enabled by using the option restore_stats. The
> >         default is for ANALYZE to retrieve rows from the remote server to
> >         locally generate statistics.
> >
> > but I think this is worse because it sounds like it can _only_ ever be
> > done by postgres_fdw.  However, if you prefer this I will make this
> > change.
> >
> > I avoided "General Performance" because frankly, it is only
> > postgres_fdw, and it not a "General" performance improvement, and we
> > have a section for postgres_fdw already.
>
> Agreed.  I think the current text is fine.

We renamed the "restore_stats" option to "import_stats".  See commit 9a08585e8.

Best regards,
Etsuro Fujita






^ permalink  raw  reply  [nested|flat] 129+ messages in thread

* Re: First draft of PG 19 release notes
@ 2026-08-18 14:44  Bruce Momjian <bruce@momjian.us>
  parent: Etsuro Fujita <etsuro.fujita@gmail.com>
  0 siblings, 1 reply; 129+ messages in thread

From: Bruce Momjian @ 2026-08-18 14:44 UTC (permalink / raw)
  To: Etsuro Fujita <etsuro.fujita@gmail.com>; +Cc: PostgreSQL-development <pgsql-hackers@lists.postgresql.org>

On Fri, Aug 14, 2026 at 07:04:46PM +0900, Etsuro Fujita wrote:
> > > but I think this is worse because it sounds like it can _only_ ever be
> > > done by postgres_fdw.  However, if you prefer this I will make this
> > > change.
> > >
> > > I avoided "General Performance" because frankly, it is only
> > > postgres_fdw, and it not a "General" performance improvement, and we
> > > have a section for postgres_fdw already.
> >
> > Agreed.  I think the current text is fine.
> 
> We renamed the "restore_stats" option to "import_stats".  See commit 9a08585e8.

Thanks, I just updated it to current and got the above plus a few more.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Do not let urgent matters crowd out time for investment in the future.






^ permalink  raw  reply  [nested|flat] 129+ messages in thread

* Re: First draft of PG 19 release notes
@ 2026-08-19 02:55  Etsuro Fujita <etsuro.fujita@gmail.com>
  parent: Bruce Momjian <bruce@momjian.us>
  0 siblings, 0 replies; 129+ messages in thread

From: Etsuro Fujita @ 2026-08-19 02:55 UTC (permalink / raw)
  To: Bruce Momjian <bruce@momjian.us>; +Cc: PostgreSQL-development <pgsql-hackers@lists.postgresql.org>

On Tue, Aug 18, 2026 at 11:44 PM Bruce Momjian <bruce@momjian.us> wrote:
> On Fri, Aug 14, 2026 at 07:04:46PM +0900, Etsuro Fujita wrote:
> > > > but I think this is worse because it sounds like it can _only_ ever be
> > > > done by postgres_fdw.  However, if you prefer this I will make this
> > > > change.
> > > >
> > > > I avoided "General Performance" because frankly, it is only
> > > > postgres_fdw, and it not a "General" performance improvement, and we
> > > > have a section for postgres_fdw already.
> > >
> > > Agreed.  I think the current text is fine.
> >
> > We renamed the "restore_stats" option to "import_stats".  See commit 9a08585e8.
>
> Thanks, I just updated it to current and got the above plus a few more.

Thank you!

Best regards,
Etsuro Fujita






^ permalink  raw  reply  [nested|flat] 129+ messages in thread

* Re: First draft of PG 19 release notes
@ 2026-08-28 05:52  Masahiko Sawada <sawada.mshk@gmail.com>
  parent: Bruce Momjian <bruce@momjian.us>
  25 siblings, 1 reply; 129+ messages in thread

From: Masahiko Sawada @ 2026-08-28 05:52 UTC (permalink / raw)
  To: Bruce Momjian <bruce@momjian.us>; +Cc: PostgreSQL-development <pgsql-hackers@lists.postgresql.org>

Hi,

On Tue, Apr 14, 2026 at 6:19 PM Bruce Momjian <bruce@momjian.us> wrote:
>
> I have completed the first draft of the PG 19 release notes:
>
>         https://www.postgresql.org/docs/devel/release-19.html
>

I have a question about the categorization of replication-related new
features. Currently the following items are listed in the "Streaming
Replication and Recovery" section:

1. Add WAIT FOR command to allow standbys to wait for LSN values to be
written, flushed, or replayed (Kartyshov Ivan, Alexander Korotkov,
Xuneng Zhou)
2 Improve function pg_sync_replication_slots() to wait for replication
synchronization completion (Ajin Cherian, Zhijie Hou)
3. Add server variable wal_sender_shutdown_timeout to limit replica
synchronization waits during shutdown (Andrey Silitskiy, Hayato
Kuroda)
4. Allow wal_receiver_timeout to be set per-subscription and user (Fujii Masao)
5. Add optional pid parameter to pg_replication_origin_session_setup()
to allow parallelization of SQL-level replication solutions (Doruk
Yilmaz, Hayato Kuroda)

I wonder if 4 and 5 should be listed in the "Logical Replication"
section instead because 4 is a new subscription option and 5 is
related to replication origins, which are used only in logical
replication. Please find the attached patch.

Regards,

-- 
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com

Attachments:

  [text/x-patch] release_note_19.patch (3.2K, ../../CAD21AoC1dJGqngg_cdT_ayQjOdw6gmSBfVOTtAWOq-5C+XeLZQ@mail.gmail.com/2-release_note_19.patch)
  download | inline diff:
diff --git a/doc/src/sgml/release-19.sgml b/doc/src/sgml/release-19.sgml
index a8046ab41f0..2cb8d4da3fe 100644
--- a/doc/src/sgml/release-19.sgml
+++ b/doc/src/sgml/release-19.sgml
@@ -1568,37 +1568,6 @@ Add server variable <link linkend="guc-wal-sender-shutdown-timeout"><varname>wal
 <para>
 By default, senders still wait forever for synchronization.
 </para>
-</listitem>
-
-<!--
-Author: Fujii Masao <fujii@postgresql.org>
-2026-02-20 [8a6af3ad0] Make GUC wal_receiver_timeout user-settable.
-Author: Fujii Masao <fujii@postgresql.org>
-2026-02-20 [fb80f388f] Add per-subscription wal_receiver_timeout setting.
--->
-
-<listitem>
-<para>
-Allow <link linkend="guc-wal-receiver-timeout"><varname>wal_receiver_timeout</varname></link> to be set per-subscription and user (Fujii Masao)
-<ulink url="&commit_baseurl;8a6af3ad0">&sect;</ulink>
-<ulink url="&commit_baseurl;fb80f388f">&sect;</ulink>
-</para>
-
-<para>
-This allows subscribers to use different <link linkend="guc-wal-receiver-timeout"><varname>wal_receiver_timeout</varname></link> values.
-</para>
-</listitem>
-
-<!--
-Author: Amit Kapila <akapila@postgresql.org>
-2025-09-19 [5b148706c] Add optional pid parameter to pg_replication_origin_sess
--->
-
-<listitem>
-<para>
-Add optional pid parameter to <link linkend="pg-replication-origin-session-setup"><function>pg_replication_origin_session_setup()</function></link> to allow parallelization of <acronym>SQL</acronym>-level replication solutions (Doruk Yilmaz, Hayato Kuroda)
-<ulink url="&commit_baseurl;5b148706c">&sect;</ulink>
-</para>
 </listitem>
 
      </itemizedlist>
@@ -1742,6 +1711,37 @@ When server variable <link linkend="guc-wal-level"><varname>wal_level</varname><
 New server variable <link linkend="guc-effective-wal-level"><varname>effective_wal_level</varname></link>, application <link linkend="app-pgcontroldata"><application>pg_controldata</application></link>,
 and function <link linkend="functions-pg-control-checkpoint"><function>pg_control_checkpoint()</function></link> report the effective <acronym>WAL</acronym> level.
 </para>
+</listitem>
+
+<!--
+Author: Fujii Masao <fujii@postgresql.org>
+2026-02-20 [8a6af3ad0] Make GUC wal_receiver_timeout user-settable.
+Author: Fujii Masao <fujii@postgresql.org>
+2026-02-20 [fb80f388f] Add per-subscription wal_receiver_timeout setting.
+-->
+
+<listitem>
+<para>
+Allow <link linkend="guc-wal-receiver-timeout"><varname>wal_receiver_timeout</varname></link> to be set per-subscription and user (Fujii Masao)
+<ulink url="&commit_baseurl;8a6af3ad0">&sect;</ulink>
+<ulink url="&commit_baseurl;fb80f388f">&sect;</ulink>
+</para>
+
+<para>
+This allows subscribers to use different <link linkend="guc-wal-receiver-timeout"><varname>wal_receiver_timeout</varname></link> values.
+</para>
+</listitem>
+
+<!--
+Author: Amit Kapila <akapila@postgresql.org>
+2025-09-19 [5b148706c] Add optional pid parameter to pg_replication_origin_sess
+-->
+
+<listitem>
+<para>
+Add optional pid parameter to <link linkend="pg-replication-origin-session-setup"><function>pg_replication_origin_session_setup()</function></link> to allow parallelization of <acronym>SQL</acronym>-level replication solutions (Doruk Yilmaz, Hayato Kuroda)
+<ulink url="&commit_baseurl;5b148706c">&sect;</ulink>
+</para>
 </listitem>
 
      </itemizedlist>


^ permalink  raw  reply  [nested|flat] 129+ messages in thread

* Re: First draft of PG 19 release notes
@ 2026-08-28 14:05  Bruce Momjian <bruce@momjian.us>
  parent: Masahiko Sawada <sawada.mshk@gmail.com>
  0 siblings, 1 reply; 129+ messages in thread

From: Bruce Momjian @ 2026-08-28 14:05 UTC (permalink / raw)
  To: Masahiko Sawada <sawada.mshk@gmail.com>; +Cc: PostgreSQL-development <pgsql-hackers@lists.postgresql.org>

On Thu, Aug 27, 2026 at 10:52:17PM -0700, Masahiko Sawada wrote:
> 4. Allow wal_receiver_timeout to be set per-subscription and user (Fujii Masao)
> 5. Add optional pid parameter to pg_replication_origin_session_setup()
> to allow parallelization of SQL-level replication solutions (Doruk
> Yilmaz, Hayato Kuroda)
> 
> I wonder if 4 and 5 should be listed in the "Logical Replication"
> section instead because 4 is a new subscription option and 5 is
> related to replication origins, which are used only in logical
> replication. Please find the attached patch.

Yes, I think you are correct.  I can't always easily identify
logical-only changes.  Patch applied, thanks.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Do not let urgent matters crowd out time for investment in the future.






^ permalink  raw  reply  [nested|flat] 129+ messages in thread

* Re: First draft of PG 19 release notes
@ 2026-09-03 09:14  =?utf-8?B?5b2t5Yay?= <chong.peng@enmotech.com>
  0 siblings, 1 reply; 129+ messages in thread

From: 彭冲 @ 2026-09-03 09:14 UTC (permalink / raw)
  To: bruce <bruce@momjian.us>; +Cc: PostgreSQL-development <pgsql-hackers@lists.postgresql.org>

Hi, Bruce


I think we should add&nbsp; this item to the release notes


"Add wait event for CommitDelay"
https://www.postgresql.org/message-id/CA+FpmFf-hWXtrC0Q3Cr_Xo78zuP_M_VC5xgWPOYOkwqOD0T8eg@mail.gmail...


Maybe we can put it in this section
```
E.1.3.1.4.&nbsp;Monitoring
```
and after&nbsp;
```
Add wait events for&nbsp;WAL&nbsp;write and flush&nbsp;LSNs
```




Best regards,--
Chong Peng
Yunhe Enmo（Beijing）Technology Co.,LTD
http://www.enmotech.com/

^ permalink  raw  reply  [nested|flat] 129+ messages in thread

* Re: First draft of PG 19 release notes
@ 2026-09-10 20:48  Masahiko Sawada <sawada.mshk@gmail.com>
  parent: Bruce Momjian <bruce@momjian.us>
  0 siblings, 1 reply; 129+ messages in thread

From: Masahiko Sawada @ 2026-09-10 20:48 UTC (permalink / raw)
  To: Bruce Momjian <bruce@momjian.us>; +Cc: PostgreSQL-development <pgsql-hackers@lists.postgresql.org>

Hi,

On Fri, Aug 28, 2026 at 7:05 AM Bruce Momjian <bruce@momjian.us> wrote:
>
> On Thu, Aug 27, 2026 at 10:52:17PM -0700, Masahiko Sawada wrote:
> > 4. Allow wal_receiver_timeout to be set per-subscription and user (Fujii Masao)
> > 5. Add optional pid parameter to pg_replication_origin_session_setup()
> > to allow parallelization of SQL-level replication solutions (Doruk
> > Yilmaz, Hayato Kuroda)
> >
> > I wonder if 4 and 5 should be listed in the "Logical Replication"
> > section instead because 4 is a new subscription option and 5 is
> > related to replication origins, which are used only in logical
> > replication. Please find the attached patch.
>
> Yes, I think you are correct.  I can't always easily identify
> logical-only changes.  Patch applied, thanks.

I found another place that we need to fix:

Add CREATE/ALTER PUBLICATION setting retain_dead_tuples to retain
information needed for conflict resolution (Zhijie Hou)

The retain_dead_tuples is a subscription option but not a
publication's one. Also, it's required for conflict detection. Please
review the attached patch that does:

s/publication/subscription/
s/conflict resolution/conflict detection/

Regards,

-- 
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com

Attachments:

  [text/x-patch] fix_max_retention_duration.patch (1.1K, ../../CAD21AoDWo7jD3wnxn3uyjvjU0qhXjzL+f_TzutEGHyyJ_RP0hQ@mail.gmail.com/2-fix_max_retention_duration.patch)
  download | inline diff:
diff --git a/doc/src/sgml/release-19.sgml b/doc/src/sgml/release-19.sgml
index 8dcdc32d7c8..60a8d5e0e9c 100644
--- a/doc/src/sgml/release-19.sgml
+++ b/doc/src/sgml/release-19.sgml
@@ -1657,7 +1657,7 @@ Author: Amit Kapila <akapila@postgresql.org>
 
 <listitem>
 <para>
-Add <link linkend="sql-createpublication"><command>CREATE</command></link>/<link linkend="sql-alterpublication"><command>ALTER PUBLICATION</command></link> setting <link linkend="sql-createsubscription-params-with-retain-dead-tuples"><varname>retain_dead_tuples</varname></link> to retain information needed for conflict resolution (Zhijie Hou)
+Add <link linkend="sql-createsubscription"><command>CREATE</command></link>/<link linkend="sql-altersubscription"><command>ALTER SUBSCRIPTION</command></link> setting <link linkend="sql-createsubscription-params-with-retain-dead-tuples"><varname>retain_dead_tuples</varname></link> to retain information needed for conflict detection (Zhijie Hou)
 <ulink url="&commit_baseurl;228c37086">&sect;</ulink>
 <ulink url="&commit_baseurl;0d48d393d">&sect;</ulink>
 <ulink url="&commit_baseurl;a850be2fe">&sect;</ulink>


^ permalink  raw  reply  [nested|flat] 129+ messages in thread

* Re: First draft of PG 19 release notes
@ 2026-09-15 02:51  Bruce Momjian <bruce@momjian.us>
  parent: =?utf-8?B?5b2t5Yay?= <chong.peng@enmotech.com>
  0 siblings, 0 replies; 129+ messages in thread

From: Bruce Momjian @ 2026-09-15 02:51 UTC (permalink / raw)
  To: 彭冲 <chong.peng@enmotech.com>; +Cc: PostgreSQL-development <pgsql-hackers@lists.postgresql.org>

On Thu, Sep  3, 2026 at 05:14:56PM +0800, 彭冲 wrote:
> Hi, Bruce
> 
> I think we should add  this item to the release notes
> 
> "Add wait event for CommitDelay"
> https://www.postgresql.org/message-id/
> CA+FpmFf-hWXtrC0Q3Cr_Xo78zuP_M_VC5xgWPOYOkwqOD0T8eg@mail.gmail.com
> 
> Maybe we can put it in this section
> ```
> E.1.3.1.4. Monitoring
> ```
> and after 
> ```
> Add wait events for WAL write and flush LSNs
> ```

Oh, good point, added.  I missed this since we don't document wait
events.  Applied patch attached.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Do not let urgent matters crowd out time for investment in the future.

Attachments:

  [text/x-diff] REL_19_STABLE.diff (1000B, ../../aqiyrOHqjr26XO04@momjian.us/2-REL_19_STABLE.diff)
  download | inline diff:
diff --git a/doc/src/sgml/release-19.sgml b/doc/src/sgml/release-19.sgml
index 118e8c09713..d1588fd8b08 100644
--- a/doc/src/sgml/release-19.sgml
+++ b/doc/src/sgml/release-19.sgml
@@ -1301,12 +1301,15 @@ Add IO wait events for <link linkend="sql-copy"><command>COPY FROM/TO</command><
 <!--
 Author: Alexander Korotkov <akorotkov@postgresql.org>
 2026-01-05 [7a39f43d8] Extend xlogwait infrastructure with write and flush wait
+Author: Heikki Linnakangas <heikki.linnakangas@iki.fi>
+2025-12-09 [3cb5808bd] Add wait event for the group commit delay before WAL flu
 -->
 
 <listitem>
 <para>
-Add wait events for <acronym>WAL</acronym> write and flush <link linkend="wal-internals">LSN</link>s (Xuneng Zhou)
+Add wait events for <xref linkend="guc-commit-delay"/> and for <acronym>WAL</acronym> write and flush <link linkend="wal-internals">LSN</link>s (Xuneng Zhou)
 <ulink url="&commit_baseurl;7a39f43d8">&sect;</ulink>
+<ulink url="&commit_baseurl;3cb5808bd">&sect;</ulink>
 </para>
 </listitem>
 

^ permalink  raw  reply  [nested|flat] 129+ messages in thread

* Re: First draft of PG 19 release notes
@ 2026-09-15 03:00  Bruce Momjian <bruce@momjian.us>
  parent: Masahiko Sawada <sawada.mshk@gmail.com>
  0 siblings, 0 replies; 129+ messages in thread

From: Bruce Momjian @ 2026-09-15 03:00 UTC (permalink / raw)
  To: Masahiko Sawada <sawada.mshk@gmail.com>; +Cc: PostgreSQL-development <pgsql-hackers@lists.postgresql.org>

On Thu, Sep 10, 2026 at 01:48:22PM -0700, Masahiko Sawada wrote:
> > Yes, I think you are correct.  I can't always easily identify
> > logical-only changes.  Patch applied, thanks.
> 
> I found another place that we need to fix:
> 
> Add CREATE/ALTER PUBLICATION setting retain_dead_tuples to retain
> information needed for conflict resolution (Zhijie Hou)
> 
> The retain_dead_tuples is a subscription option but not a
> publication's one. Also, it's required for conflict detection. Please
> review the attached patch that does:
> 
> s/publication/subscription/
> s/conflict resolution/conflict detection/

Yep, seems I have problems with logical-only changes, and in
publication/subscription details too.  Thanks for the patch, applied.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Do not let urgent matters crowd out time for investment in the future.






^ permalink  raw  reply  [nested|flat] 129+ messages in thread

* Re: First draft of PG 19 release notes
@ 2026-10-12 06:55  Antonin Houska <ah@cybertec.at>
  parent: Bruce Momjian <bruce@momjian.us>
  25 siblings, 1 reply; 129+ messages in thread

From: Antonin Houska @ 2026-10-12 06:55 UTC (permalink / raw)
  To: Bruce Momjian <bruce@momjian.us>; +Cc: PostgreSQL-development <pgsql-hackers@lists.postgresql.org>

Bruce Momjian <bruce@momjian.us> wrote:

> I have completed the first draft of the PG 19 release notes:
> 
> 	https://www.postgresql.org/docs/devel/release-19.html

This diff reflects the commit 01a80f0621 (in the REL_19_STABLE branch).

-- 
Antonin Houska
Web: https://www.cybertec-postgresql.com

Attachments:

  [text/x-diff] doc_revert_0d3dba38c777.diff (822B, ../../5973.1791788107@localhost/2-doc_revert_0d3dba38c777.diff)
  download | inline diff:
diff --git a/doc/src/sgml/release-19.sgml b/doc/src/sgml/release-19.sgml
index 60db47953e1..d80582a8ddf 100644
--- a/doc/src/sgml/release-19.sgml
+++ b/doc/src/sgml/release-19.sgml
@@ -2924,18 +2924,6 @@ Change function prototypes to use <literal>uint*</literal> instead of <literal>b
 </para>
 </listitem>
 
-<!--
-Author: Álvaro Herrera <alvherre@kurilemu.de>
-2026-04-07 [0d3dba38c] Allow logical replication snapshots to be database-speci
--->
-
-<listitem>
-<para>
-Allow <link linkend="logicaldecoding-pgoutput">logical decoding plugins</link> to specify if they do not access shared catalogs (Antonin Houska)
-<ulink url="&commit_baseurl;0d3dba38c">&sect;</ulink>
-</para>
-</listitem>
-
 <!--
 Author: Jacob Champion <jchampion@postgresql.org>
 2026-04-03 [d438a3659] oauth: Let validators provide failure DETAILs

^ permalink  raw  reply  [nested|flat] 129+ messages in thread

* Re: First draft of PG 19 release notes
@ 2026-10-13 00:46  Bruce Momjian <bruce@momjian.us>
  parent: Antonin Houska <ah@cybertec.at>
  0 siblings, 0 replies; 129+ messages in thread

From: Bruce Momjian @ 2026-10-13 00:46 UTC (permalink / raw)
  To: Antonin Houska <ah@cybertec.at>; +Cc: PostgreSQL-development <pgsql-hackers@lists.postgresql.org>

On Mon, Oct 12, 2026 at 08:55:07AM +0200, Antonin Houska wrote:
> Bruce Momjian <bruce@momjian.us> wrote:
> 
> > I have completed the first draft of the PG 19 release notes:
> > 
> > 	https://www.postgresql.org/docs/devel/release-19.html
> 
> This diff reflects the commit 01a80f0621 (in the REL_19_STABLE branch).

Ah, thank you for this, committed.  I was more focused on the commit
text and missed seeing that the reverted commit subject matched a
release note item.

Reverted release note items should never appear in the release notes,
and I bet AI could easily detect this mistake.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Do not let urgent matters crowd out time for investment in the future.






^ permalink  raw  reply  [nested|flat] 129+ messages in thread

end of thread, other threads:[~2026-10-13 00:46 UTC | newest]

Thread overview: 129+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2025-11-06 00:22 [PATCH v6 04/14] bufmgr: Change BufferDesc.state to be a 64bit atomic Andres Freund <andres@anarazel.de>
2025-12-02 23:46 [PATCH v7 11/15] bufmgr: Change BufferDesc.state to be a 64bit atomic Andres Freund <andres@anarazel.de>
2025-12-18 23:28 [PATCH v8 06/10] bufmgr: Change BufferDesc.state to be a 64bit atomic Andres Freund <andres@anarazel.de>
2026-01-14 01:10 [PATCH v11 1/7] bufmgr: Change BufferDesc.state to be a 64-bit atomic Andres Freund <andres@anarazel.de>
2026-04-15 01:18 First draft of PG 19 release notes Bruce Momjian <bruce@momjian.us>
2026-04-15 01:53 ` Re: First draft of PG 19 release notes Bruce Momjian <bruce@momjian.us>
2026-04-15 02:25 ` Re: First draft of PG 19 release notes Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>
2026-04-15 16:57   ` Re: First draft of PG 19 release notes Bruce Momjian <bruce@momjian.us>
2026-04-15 17:21     ` Re: First draft of PG 19 release notes Jacob Champion <jacob.champion@enterprisedb.com>
2026-04-15 19:27       ` Re: First draft of PG 19 release notes Bruce Momjian <bruce@momjian.us>
2026-04-16 07:54         ` Re: First draft of PG 19 release notes Michael Banck <mbanck@gmx.net>
2026-04-16 15:13           ` Re: First draft of PG 19 release notes Bruce Momjian <bruce@momjian.us>
2026-04-16 02:22     ` Re: First draft of PG 19 release notes Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>
2026-04-15 02:29 ` Re: First draft of PG 19 release notes David Rowley <dgrowleyml@gmail.com>
2026-04-15 18:41   ` Re: First draft of PG 19 release notes Bruce Momjian <bruce@momjian.us>
2026-04-15 19:34     ` Re: First draft of PG 19 release notes Bruce Momjian <bruce@momjian.us>
2026-04-15 05:27 ` Re: First draft of PG 19 release notes Peter Smith <smithpb2250@gmail.com>
2026-04-15 19:35   ` Re: First draft of PG 19 release notes Bruce Momjian <bruce@momjian.us>
2026-04-15 08:57 ` Re: First draft of PG 19 release notes Laurenz Albe <laurenz.albe@cybertec.at>
2026-04-15 19:38   ` Re: First draft of PG 19 release notes Bruce Momjian <bruce@momjian.us>
2026-04-15 11:18 ` Re: First draft of PG 19 release notes Daniel Gustafsson <daniel@yesql.se>
2026-04-15 19:46   ` Re: First draft of PG 19 release notes Bruce Momjian <bruce@momjian.us>
2026-04-15 14:59 ` Re: First draft of PG 19 release notes jian he <jian.universality@gmail.com>
2026-04-15 20:18   ` Re: First draft of PG 19 release notes Bruce Momjian <bruce@momjian.us>
2026-04-15 17:56 ` Re: First draft of PG 19 release notes Melanie Plageman <melanieplageman@gmail.com>
2026-04-15 20:51   ` Re: First draft of PG 19 release notes Bruce Momjian <bruce@momjian.us>
2026-04-16 05:47 ` Re: First draft of PG 19 release notes Masahiko Sawada <sawada.mshk@gmail.com>
2026-04-16 15:24   ` Re: First draft of PG 19 release notes Bruce Momjian <bruce@momjian.us>
2026-04-16 06:38 ` Re: First draft of PG 19 release notes David Geier <geidav.pg@gmail.com>
2026-04-16 16:14   ` Re: First draft of PG 19 release notes Bruce Momjian <bruce@momjian.us>
2026-04-17 14:40     ` Re: First draft of PG 19 release notes David Geier <geidav.pg@gmail.com>
2026-04-17 14:44       ` Re: First draft of PG 19 release notes Bruce Momjian <bruce@momjian.us>
2026-04-19 11:27         ` Re: First draft of PG 19 release notes David Geier <geidav.pg@gmail.com>
2026-04-19 13:32           ` Re: First draft of PG 19 release notes Bruce Momjian <bruce@momjian.us>
2026-04-19 15:10             ` Re: First draft of PG 19 release notes Andres Freund <andres@anarazel.de>
2026-04-19 17:53               ` Re: First draft of PG 19 release notes Bruce Momjian <bruce@momjian.us>
2026-04-19 18:04                 ` Re: First draft of PG 19 release notes Andres Freund <andres@anarazel.de>
2026-04-19 18:36                   ` Re: First draft of PG 19 release notes Bruce Momjian <bruce@momjian.us>
2026-04-19 19:25                     ` Re: First draft of PG 19 release notes Andres Freund <andres@anarazel.de>
2026-04-20 01:30                       ` Re: First draft of PG 19 release notes David Rowley <dgrowleyml@gmail.com>
2026-04-20 09:10                         ` Re: First draft of PG 19 release notes Bruce Momjian <bruce@momjian.us>
2026-04-20 10:40                           ` Re: First draft of PG 19 release notes David Rowley <dgrowleyml@gmail.com>
2026-04-20 16:12                             ` Re: First draft of PG 19 release notes Bruce Momjian <bruce@momjian.us>
2026-04-21 15:52                               ` Re: First draft of PG 19 release notes Andres Freund <andres@anarazel.de>
2026-04-21 20:28                                 ` Re: First draft of PG 19 release notes Bruce Momjian <bruce@momjian.us>
2026-04-21 20:41                                 ` Re: First draft of PG 19 release notes Bruce Momjian <bruce@momjian.us>
2026-04-21 20:18                             ` Re: First draft of PG 19 release notes Bruce Momjian <bruce@momjian.us>
2026-04-21 21:17                               ` Re: First draft of PG 19 release notes Bruce Momjian <bruce@momjian.us>
2026-04-22 07:11                                 ` Re: First draft of PG 19 release notes Bruce Momjian <bruce@momjian.us>
2026-04-23 15:10                                   ` Re: First draft of PG 19 release notes Bruce Momjian <bruce@momjian.us>
2026-05-07 20:20                                     ` Re: First draft of PG 19 release notes Bruce Momjian <bruce@momjian.us>
2026-04-16 07:49 ` Re: First draft of PG 19 release notes Richard Guo <guofenglinux@gmail.com>
2026-04-16 16:45   ` Re: First draft of PG 19 release notes Bruce Momjian <bruce@momjian.us>
2026-04-20 10:07 ` Re: First draft of PG 19 release notes shammat@gmx.net
2026-04-20 11:15   ` Re: First draft of PG 19 release notes Bruce Momjian <bruce@momjian.us>
2026-04-20 13:03 ` Re: First draft of PG 19 release notes Xuneng Zhou <xunengzhou@gmail.com>
2026-05-07 22:01   ` Re: First draft of PG 19 release notes Bruce Momjian <bruce@momjian.us>
2026-04-21 12:24 ` Re: First draft of PG 19 release notes Etsuro Fujita <etsuro.fujita@gmail.com>
2026-05-07 23:08   ` Re: First draft of PG 19 release notes Bruce Momjian <bruce@momjian.us>
2026-05-09 09:15     ` Re: First draft of PG 19 release notes Etsuro Fujita <etsuro.fujita@gmail.com>
2026-08-14 10:04       ` Re: First draft of PG 19 release notes Etsuro Fujita <etsuro.fujita@gmail.com>
2026-08-18 14:44         ` Re: First draft of PG 19 release notes Bruce Momjian <bruce@momjian.us>
2026-08-19 02:55           ` Re: First draft of PG 19 release notes Etsuro Fujita <etsuro.fujita@gmail.com>
2026-04-22 03:10 ` Re: First draft of PG 19 release notes jian he <jian.universality@gmail.com>
2026-05-08 00:20   ` Re: First draft of PG 19 release notes Bruce Momjian <bruce@momjian.us>
2026-04-30 07:08 ` Re: First draft of PG 19 release notes Andreas Karlsson <andreas@proxel.se>
2026-04-30 07:16   ` Re: First draft of PG 19 release notes Andreas Karlsson <andreas@proxel.se>
2026-05-01 13:24     ` RE: First draft of PG 19 release notes Phil Florent <philflorent@hotmail.com>
2026-05-08 00:52       ` Re: First draft of PG 19 release notes Bruce Momjian <bruce@momjian.us>
2026-05-01 01:16 ` Re: First draft of PG 19 release notes Richard Guo <guofenglinux@gmail.com>
2026-05-08 00:54   ` Re: First draft of PG 19 release notes Bruce Momjian <bruce@momjian.us>
2026-05-11 05:40     ` Re: First draft of PG 19 release notes John Naylor <johncnaylorls@gmail.com>
2026-05-11 21:42       ` Re: First draft of PG 19 release notes Bruce Momjian <bruce@momjian.us>
2026-05-12 02:34         ` Re: First draft of PG 19 release notes Robert Treat <rob@xzilla.net>
2026-05-12 03:38           ` Re: First draft of PG 19 release notes John Naylor <johncnaylorls@gmail.com>
2026-05-12 19:11             ` Re: First draft of PG 19 release notes Bruce Momjian <bruce@momjian.us>
2026-05-12 04:11 ` Re: First draft of PG 19 release notes jian he <jian.universality@gmail.com>
2026-05-12 20:15   ` Re: First draft of PG 19 release notes Bruce Momjian <bruce@momjian.us>
2026-05-12 12:41 ` Re: First draft of PG 19 release notes Greg Sabino Mullane <htamfids@gmail.com>
2026-05-12 14:57   ` Re: First draft of PG 19 release notes Melanie Plageman <melanieplageman@gmail.com>
2026-05-12 20:31     ` Re: First draft of PG 19 release notes Bruce Momjian <bruce@momjian.us>
2026-05-12 20:27   ` Re: First draft of PG 19 release notes Bruce Momjian <bruce@momjian.us>
2026-05-15 16:31 ` Re: First draft of PG 19 release notes Peter Geoghegan <pg@bowt.ie>
2026-05-15 17:27   ` Re: First draft of PG 19 release notes Bruce Momjian <bruce@momjian.us>
2026-05-26 05:25     ` Re: First draft of PG 19 release notes Chao Li <li.evan.chao@gmail.com>
2026-05-26 15:00       ` Re: First draft of PG 19 release notes Bruce Momjian <bruce@momjian.us>
2026-05-26 15:46         ` Re: First draft of PG 19 release notes Thom Brown <thom@linux.com>
2026-05-26 20:32           ` Re: First draft of PG 19 release notes Bruce Momjian <bruce@momjian.us>
2026-05-26 21:14             ` Re: First draft of PG 19 release notes Thom Brown <thom@linux.com>
2026-05-26 21:49               ` Re: First draft of PG 19 release notes Bruce Momjian <bruce@momjian.us>
2026-06-05 08:11 ` Re: First draft of PG 19 release notes Yugo Nagata <nagata@sraoss.co.jp>
2026-06-05 13:55   ` Re: First draft of PG 19 release notes Bruce Momjian <bruce@momjian.us>
2026-06-05 18:14     ` Re: First draft of PG 19 release notes Bruce Momjian <bruce@momjian.us>
2026-06-05 18:58       ` Re: First draft of PG 19 release notes Bruce Momjian <bruce@momjian.us>
2026-06-05 19:17         ` Re: First draft of PG 19 release notes Baji Shaik <baji.pgdev@gmail.com>
2026-06-05 19:29           ` Re: First draft of PG 19 release notes Bruce Momjian <bruce@momjian.us>
2026-06-06 13:08         ` Re: First draft of PG 19 release notes Álvaro Herrera <alvherre@kurilemu.de>
2026-06-08 03:43           ` Re: First draft of PG 19 release notes Bruce Momjian <bruce@momjian.us>
2026-06-08 14:13             ` Re: First draft of PG 19 release notes Bruce Momjian <bruce@momjian.us>
2026-06-09 06:59               ` Re: First draft of PG 19 release notes Chao Li <li.evan.chao@gmail.com>
2026-06-16 18:14                 ` Re: First draft of PG 19 release notes Bruce Momjian <bruce@momjian.us>
2026-06-11 09:01 ` Re: First draft of PG 19 release notes Srinath Reddy Sadipiralla <srinath2133@gmail.com>
2026-06-16 23:41   ` Re: First draft of PG 19 release notes Bruce Momjian <bruce@momjian.us>
2026-06-18 01:29 ` Re: First draft of PG 19 release notes Fujii Masao <masao.fujii@gmail.com>
2026-06-18 01:34   ` Re: First draft of PG 19 release notes Bruce Momjian <bruce@momjian.us>
2026-06-18 01:45     ` Re: First draft of PG 19 release notes Bruce Momjian <bruce@momjian.us>
2026-06-25 02:57       ` Re: First draft of PG 19 release notes Chao Li <li.evan.chao@gmail.com>
2026-06-29 21:39         ` Re: First draft of PG 19 release notes Bruce Momjian <bruce@momjian.us>
2026-07-02 22:12 ` Re: First draft of PG 19 release notes Andreas Karlsson <andreas@proxel.se>
2026-07-02 22:16   ` Re: First draft of PG 19 release notes Andreas Karlsson <andreas@proxel.se>
2026-07-15 09:56     ` Re: First draft of PG 19 release notes Bruce Momjian <bruce@momjian.us>
2026-07-15 21:55       ` Re: First draft of PG 19 release notes Bruce Momjian <bruce@momjian.us>
2026-07-16 20:38         ` Re: First draft of PG 19 release notes Jacob Champion <jacob.champion@enterprisedb.com>
2026-07-17 20:04           ` Re: First draft of PG 19 release notes Bruce Momjian <bruce@momjian.us>
2026-07-17 22:03             ` Re: First draft of PG 19 release notes Chao Li <li.evan.chao@gmail.com>
2026-07-19 00:50               ` Re: First draft of PG 19 release notes Bruce Momjian <bruce@momjian.us>
2026-07-02 22:35   ` Re: First draft of PG 19 release notes Jacob Champion <jacob.champion@enterprisedb.com>
2026-08-28 05:52 ` Re: First draft of PG 19 release notes Masahiko Sawada <sawada.mshk@gmail.com>
2026-08-28 14:05   ` Re: First draft of PG 19 release notes Bruce Momjian <bruce@momjian.us>
2026-09-10 20:48     ` Re: First draft of PG 19 release notes Masahiko Sawada <sawada.mshk@gmail.com>
2026-09-15 03:00       ` Re: First draft of PG 19 release notes Bruce Momjian <bruce@momjian.us>
2026-10-12 06:55 ` Re: First draft of PG 19 release notes Antonin Houska <ah@cybertec.at>
2026-10-13 00:46   ` Re: First draft of PG 19 release notes Bruce Momjian <bruce@momjian.us>
2026-05-29 03:30 Re: First draft of PG 19 release notes =?utf-8?B?5b2t5Yay?= <chong.peng@enmotech.com>
2026-05-30 18:57 ` Re: First draft of PG 19 release notes Bruce Momjian <bruce@momjian.us>
2026-06-04 00:51 Re: First draft of PG 19 release notes =?utf-8?B?5b2t5Yay?= <chong.peng@enmotech.com>
2026-06-04 02:27 ` Re: First draft of PG 19 release notes Bruce Momjian <bruce@momjian.us>
2026-09-03 09:14 Re: First draft of PG 19 release notes =?utf-8?B?5b2t5Yay?= <chong.peng@enmotech.com>
2026-09-15 02:51 ` Re: First draft of PG 19 release notes Bruce Momjian <bruce@momjian.us>

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox