Life with Open Source

commit   : c4117066ba9f7b1cfb36eb634c0c306785748b80    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Sat, 10 Oct 2026 10:26:18 -0400    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Sat, 10 Oct 2026 10:26:18 -0400    

A hash index scan whose target bucket is still being populated by a  
split must read both buckets of the split: forward scans read the bucket  
being populated (skipping the tuples that the split copied there) and  
then the bucket being split, and backward scans read them in the  
opposite order.  _hash_readnext and _hash_readprev make the transition  
from the first bucket to the second, but _hash_next did not: on reaching  
the end of the first bucket, it ended the scan, so every matching tuple  
in the second bucket was overlooked.  
  
To fix, teach _hash_next to make the same transition, using helper  
functions shared with _hash_readnext and _hash_readprev.  
  
_hash_next only missed the transition when the last page that it read in  
the first bucket had a match (otherwise _hash_readpage's loop made the  
required transition).  Getting wrong answers also needed a matching  
tuple to be inserted into the bucket being populated _after_ the split  
began.  Forward scans then lost the older tuples in the bucket being  
split.  An incomplete split would keep the buckets in this state until  
an inserter finished the split at some indeterminate later time.  Note  
that wrong answers didn't require an incomplete split.  
  
Although this fix treats the bug as the omission of a required step in  
_hash_next, the real problem is the way that page stepping works in  
general.  The logic for stepping to the next page appears both in  
high-level routines like _hash_next and in low-level routines like  
_hash_readnext and _hash_readprev.  If anything, _hash_next already knew  
too much about page stepping (cf. nbtree's _bt_next function).  All of  
the logic around stepping really belongs in one routine, modeled on  
nbtree's _bt_steppage function, but that approach is much too invasive  
for a backpatched fix.  
  
Claude Code found this problem.  The committed test case is a simplified  
version of the one that it wrote to demonstrate this bug.  
  
Oversight in commit 7c75ef57, which introduced page-at-a-time processing  
of hash index scans.  
  
Author: Peter Geoghegan <pg@bowt.ie>  
Author: Amit Kapila <amit.kapila16@gmail.com>  
Reviewed-by: Vignesh C <vignesh21@gmail.com>  
Discussion: https://postgr.es/m/CAH2-Wz=4CJK9ysZzbzxBGGTkgAg9ib8cJyCx=9q_d1r8tf0ang@mail.gmail.com  
Backpatch-through: 14  

commit   : 173cf85a079516fdd2b09ed853702b05fbfcd15e    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Sat, 10 Oct 2026 10:26:18 -0400    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Sat, 10 Oct 2026 10:26:18 -0400    

A hash index scan whose target bucket is still being populated by a  
split must read both buckets of the split: forward scans read the bucket  
being populated (skipping the tuples that the split copied there) and  
then the bucket being split, and backward scans read them in the  
opposite order.  _hash_readnext and _hash_readprev make the transition  
from the first bucket to the second, but _hash_next did not: on reaching  
the end of the first bucket, it ended the scan, so every matching tuple  
in the second bucket was overlooked.  
  
To fix, teach _hash_next to make the same transition, using helper  
functions shared with _hash_readnext and _hash_readprev.  
  
_hash_next only missed the transition when the last page that it read in  
the first bucket had a match (otherwise _hash_readpage's loop made the  
required transition).  Getting wrong answers also needed a matching  
tuple to be inserted into the bucket being populated _after_ the split  
began.  Forward scans then lost the older tuples in the bucket being  
split.  An incomplete split would keep the buckets in this state until  
an inserter finished the split at some indeterminate later time.  Note  
that wrong answers didn't require an incomplete split.  
  
Although this fix treats the bug as the omission of a required step in  
_hash_next, the real problem is the way that page stepping works in  
general.  The logic for stepping to the next page appears both in  
high-level routines like _hash_next and in low-level routines like  
_hash_readnext and _hash_readprev.  If anything, _hash_next already knew  
too much about page stepping (cf. nbtree's _bt_next function).  All of  
the logic around stepping really belongs in one routine, modeled on  
nbtree's _bt_steppage function, but that approach is much too invasive  
for a backpatched fix.  
  
Claude Code found this problem.  The committed test case is a simplified  
version of the one that it wrote to demonstrate this bug.  
  
Oversight in commit 7c75ef57, which introduced page-at-a-time processing  
of hash index scans.  
  
Author: Peter Geoghegan <pg@bowt.ie>  
Author: Amit Kapila <amit.kapila16@gmail.com>  
Reviewed-by: Vignesh C <vignesh21@gmail.com>  
Discussion: https://postgr.es/m/CAH2-Wz=4CJK9ysZzbzxBGGTkgAg9ib8cJyCx=9q_d1r8tf0ang@mail.gmail.com  
Backpatch-through: 14  

commit   : 46cdca625a73403cad4774d97354a1fac1e91e51    
  
author   : David Steele <david@pgbackrest.org>    
date     : Sun, 4 Oct 2026 09:29:49 +0200    
  
committer: David Steele <david@pgbackrest.org>    
date     : Sun, 4 Oct 2026 09:29:49 +0200    

IMPORTANT NOTE: In prior versions it was possible for weak encryption subkeys and salts to be generated if there was an error accessing system random data.  
  
Bug Fixes:  
  
* Fix possible checksum error loading encrypted info and manifest files. (Fixed by j0uinim. Reviewed by David Steele.)  
* Fix possible weak encryption subkeys/salts. (Fixed by j0uinim. Reviewed by David Steele, Stefan Fercot, Douglas J Hunley.)  

commit   : d5138e2e3b92fe806505bc8b9c69f36bd70cea18    
  
author   : David Steele <david@pgbackrest.org>    
date     : Sun, 27 Sep 2026 14:15:45 +0300    
  
committer: David Steele <david@pgbackrest.org>    
date     : Sun, 27 Sep 2026 14:15:45 +0300    

Bug Fixes:  
  
* Fix empty block map when file is truncated to zero during backup. (Reviewed by Douglas J Hunley. Reported by JPCOSTA78.)  
* Disable read retry when filters are passed to the driver. (Reviewed by Douglas J Hunley. Reported by megamaced.)  
* Fix pagination of S3 version listing. (Reviewed by Douglas J Hunley, guruguruguru. Reported by guruguruguru.)  
* Set the Azure version header for SAS authentication. (Reviewed by Douglas J Hunley. Reported by Florian Helmberger.)  
* Fix async archive-push stalling on a zero-size backup history file. (Fixed by Andrew Kroh. Reviewed by David Steele, Douglas J Hunley.)  
* Fix annotate command on a remote encrypted repository. (Fixed by Douglas J Hunley. Reviewed by David Steele.)  
  
Features:  
  
* PostgreSQL 19beta4 support.  

commit   : 8c8f3ee63e310f0b3ea10b55ed3b96b4cc9296da    
  
author   : David Steele <david@pgbackrest.org>    
date     : Mon, 17 Aug 2026 16:08:40 +0700    
  
committer: David Steele <david@pgbackrest.org>    
date     : Mon, 17 Aug 2026 16:08:40 +0700    

Bug Fixes:  
  
* Fix hang when the chunk buffer is smaller than the input buffer. (Reviewed by Andrew Pogrebnoi, Douglas J Hunley. Reported by crajac66.)  
* Compare a new backup label only against its own full backup set. (Reviewed by Douglas J Hunley. Reported by Anton Glushakov.)  
* Fix source archives generated by GitHub missing files required to build. (Reported by aardvarkzed.)  
  
Features:  
  
* PostgreSQL 19beta3 support. (Contributed by Lardière Sébastien. Reviewed by David Steele.)  
  
Documentation Improvements:  
  
* Document exception for dots in S3 bucket names when repo-s3-uri-style=path.  
* Remove explicit hot_standby configuration from user guide.  

commit   : 724edf9bde9d356724ad384a2e196edc3c9f80f7    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 11 Aug 2026 14:38:31 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 11 Aug 2026 14:38:31 -0400    

commit   : 841d0cb0f9b8b1b25e7b299ac0eb134074b45a08    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 11 Aug 2026 14:37:01 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 11 Aug 2026 14:37:01 -0400    

commit   : 6b3806732b7c5df06bdd0ed150e8a07b4ad62315    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 Aug 2026 16:59:18 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 Aug 2026 16:59:18 -0400    

commit   : 18ec528b8c3804f4c101e3a8d091ada7c5a40bb4    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 Aug 2026 12:35:49 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 Aug 2026 12:35:49 -0400    

commit   : 2ff1375b5dd8bf09d8cb0e795974528180fd75ca    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 Aug 2026 16:57:41 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 Aug 2026 16:57:41 -0400    

commit   : 492b517f362a4325bbcd6c1aa6f1204b7696d7ed    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 Aug 2026 12:35:48 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 Aug 2026 12:35:48 -0400    

commit   : 7d3e000c5961a544302072058a1184e9a588837b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 Aug 2026 16:56:00 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 Aug 2026 16:56:00 -0400    

commit   : a5c8e521cf9e2d2334cf3c94ed64edb397b00e01    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 Aug 2026 12:35:48 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 Aug 2026 12:35:48 -0400    

commit   : 083ac033419f690758508e08c1736089384bbee8    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 Aug 2026 16:54:09 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 Aug 2026 16:54:09 -0400    

commit   : 83bb18b714e7b98c243083d2480828331601de23    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 Aug 2026 12:35:48 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 Aug 2026 12:35:48 -0400