PostgreSQL 15.12 commit log

commit   : 50d3d22baba63613d1f1406b2ed460dc9b03c3fc    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 17 Feb 2025 16:14:22 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 17 Feb 2025 16:14:22 -0500    

commit   : f815362abecde1aebcd9ddb334fe271edc759eaa    
  
author   : Álvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 17 Feb 2025 17:51:30 +0100    
  
committer: Álvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 17 Feb 2025 17:51:30 +0100    

Source-Git-URL: ssh://git@git.postgresql.org/pgtranslation/messages.git  
Source-Git-Hash: af39eb1d27d7701ff7240457c2c9e49e9531eaa7  

commit   : 4444c479dc817800c074400e0423c77e3d9de35d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 16 Feb 2025 14:20:33 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 16 Feb 2025 14:20:33 -0500    

commit   : 2226a2e266dbabc5597fff5f624b3fcd71ce5fa8    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 16 Feb 2025 12:46:35 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 16 Feb 2025 12:46:35 -0500    

Coverity complained that we weren't doing that, and it's right.  
  
This fix just makes fmtIdEnc() honor the general convention that OOM  
causes a PQExpBuffer to become marked "broken", without any immediate  
error.  In the pretty-unlikely case that we actually did hit OOM here,  
the end result would be to return an empty string to the caller,  
probably resulting in invalid SQL syntax in an issued command (if  
nothing else went wrong, which is even more unlikely).  It's tempting  
to throw an "out of memory" error if the buffer becomes broken, but  
there's not a lot of point in doing that only here and not in hundreds  
of other PQExpBuffer-using places in pg_dump and similar callers.  
The whole issue could do with some non-time-crunched redesign, perhaps.  
  
This is a followup to the fixes for CVE-2025-1094, and should be  
included if cherry-picking those fixes.  

commit   : e782a63ccb76a8db476abb8f5d96397806e3e51b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 15 Feb 2025 16:20:21 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 15 Feb 2025 16:20:21 -0500    

Instead of dropping the trailing byte(s) of an invalid or incomplete  
multibyte character, replace only the first byte with a known-invalid  
sequence, and process the rest normally.  This seems less likely to  
confuse incautious callers than the behavior adopted in 5dc1e42b4.  
  
While we're at it, adjust PQescapeStringInternal to produce at most  
one bleat about invalid multibyte characters per string.  This  
matches the behavior of PQescapeInternal, and avoids the risk of  
producing tons of repetitive junk if a long string is simply given  
in the wrong encoding.  
  
This is a followup to the fixes for CVE-2025-1094, and should be  
included if cherry-picking those fixes.  
  
Author: Andres Freund <andres@anarazel.de>  
Co-authored-by: Tom Lane <tgl@sss.pgh.pa.us>  
Reported-by: Jeff Davis <pgsql@j-davis.com>  
Discussion: https://postgr.es/m/20250215012712.45@rfd.leadboat.com  
Backpatch-through: 13  

commit   : 22ffbbf24db4e5996abcf376ef1735346d4b6f75    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Fri, 14 Feb 2025 17:44:28 -0500    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Fri, 14 Feb 2025 17:44:28 -0500    

In 5dc1e42b4fa I fixed bugs in various escape functions, unfortunately as part  
of that I introduced a new bug in PQescapeLiteral()/PQescapeIdentifier(). The  
bug is that I made PQescapeInternal() just use strlen(), rather than taking  
the specified input length into account.  
  
That's bad, because it can lead to including input that wasn't intended to be  
included (in case len is shorter than null termination of the string) and  
because it can lead to reading invalid memory if the input string is not null  
terminated.  
  
Expand test_escape to this kind of bug:  
  
a) for escape functions with length support, append data that should not be  
   escaped and check that it is not  
  
b) add valgrind requests to detect access of bytes that should not be touched  
  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Author: Andres Freund <andres@anarazel.de  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Reviewed-by: Noah Misch <noah@leadboat.com>  
Discussion: https://postgr.es/m/Z64jD3u46gObCo1p@pryzbyj2023  
Backpatch: 13  

commit   : cb19cd956f685558b5b6b3d49db6cff01d35726f    
  
author   : Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Fri, 14 Feb 2025 11:50:56 +0100    
  
committer: Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Fri, 14 Feb 2025 11:50:56 +0100    

Commit 27cc7cd2bc8a accidentally placed the assertion ensuring  
that the pointer isn't NULL after it had already been accessed.  
Fix by moving the pointer dereferencing to after the assertion.  
Backpatch to all supported branches.  
  
Author: Dmitry Koval <d.koval@postgrespro.ru>  
Reviewed-by: Daniel Gustafsson <daniel@yesql.se>  
Reviewed-by: Michael Paquier <michael@paquier.xyz>  
Discussion: https://postgr.es/m/1618848d-cdc7-414b-9c03-08cf4bef4408@postgrespro.ru  
Backpatch-through: 13  

commit   : a37c83d1e465399fb1398507b6634f4dce76964c    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 13 Feb 2025 16:31:10 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 13 Feb 2025 16:31:10 +0900    

When an UPDATE trigger referencing a new table and a DELETE trigger  
referencing an old table are both present, MakeTransitionCaptureState()  
returns an inconsistent result for UPDATE commands in its set of flags  
and tuplestores holding the TransitionCaptureState for transition  
tables.  
  
As proved by the test added here, this issue causes a crash in v14 and  
earlier versions (down to 11, actually, older versions do not support  
triggers on partitioned tables) during cross-partition updates on a  
partitioned table.  v15 and newer versions are safe thanks to  
7103ebb7aae8.  
  
This commit fixes the function so that it returns a consistent state  
by using portions of the changes made in commit 7103ebb7aae8 for v13 and  
v14.  v15 and newer versions are slightly tweaked to match with the  
older versions, mainly for consistency across branches.  
  
Author: Kyotaro Horiguchi  
Discussion: https://postgr.es/m/20250207.150238.968446820828052276.horikyota.ntt@gmail.com  
Backpatch-through: 13  

commit   : 9efd78ef6b091904d05db16eacc7c61540087118    
  
author   : John Naylor <john.naylor@postgresql.org>    
date     : Wed, 12 Feb 2025 13:37:59 +0700    
  
committer: John Naylor <john.naylor@postgresql.org>    
date     : Wed, 12 Feb 2025 13:37:59 +0700    

Author: 斉藤登 <noborusai@gmail.com>  
Reviewed-by: David G. Johnston <david.g.johnston@gmail.com>  
Discussion: https://postgr.es/m/CAAM3qnL6i-BSu5rB2+KiHLjMCOXiQEiPMBvEj7F1CgUzZMooLA@mail.gmail.com  
Backpatch-through: 13