Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mmiSJ-0003Q7-6K for pgsql-announce@arkaria.postgresql.org; Mon, 15 Nov 2021 20:19:55 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1mmiSH-00033e-Tr for pgsql-announce@arkaria.postgresql.org; Mon, 15 Nov 2021 20:19:53 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mmiPf-0002J9-NB for pgsql-announce@lists.postgresql.org; Mon, 15 Nov 2021 20:17:12 +0000 Received: from mahout.postgresql.org ([2001:4800:3e1:1::227]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mmiPY-0005m7-DO for pgsql-announce@lists.postgresql.org; Mon, 15 Nov 2021 20:17:10 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=postgresql.org; s=20171124; h=Message-ID:Date:Reply-To:From:To:Subject: MIME-Version:Content-Type:Sender:Cc:Content-Transfer-Encoding:Content-ID: Content-Description:In-Reply-To:References; bh=OF//btzN/Koi4Yr2VJ0Y5aczUK0R1Yq3Z1O7MyU6D8E=; b=xGRtv5RFD7k7QmdEYT6iq7u6RX jP/sy8k1d11/LVL916EaumoCKlUEC7Qw5XftGvo+geqp00ZW9VoPPWWdZfZfLyJUtI6vFTH28hVyu zQqK22GPbs+3U2exHFxdnlQugs4bUSxToyU7LO36ghdlqRL+FwXH9UeYINVAmhKZGX5HymN/g5oYg rdtf19XpNie1WWIIdq68vvRKVetk8fr9uX+8HSpjVqJ8I4PqPHNlGE+iWTYLVY/hKuhPVsdV82HS2 r6wnqQKZRvxZjAeomftut8i8Bn8R3p6uFN69gXYh+DrMNmiB6jsaZRiXIZ781IGVVLIGlMFxzQ56p pHigjP3w==; Received: from wrigleys.postgresql.org ([2a02:c0:301:0:ffff::34]) by mahout.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mmiPX-0003r9-C8 for pgsql-announce@lists.postgresql.org; Mon, 15 Nov 2021 20:17:04 +0000 Received: from localhost ([127.0.0.1] helo=wrigleys.postgresql.org) by wrigleys.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1mmiPW-0007CN-58 for pgsql-announce@lists.postgresql.org; Mon, 15 Nov 2021 20:17:02 +0000 Content-Type: multipart/mixed; boundary="===============6840132456155053707==" MIME-Version: 1.0 Subject: PostgreSQL Weekly News - November 14, 2021 To: PostgreSQL Announce From: PWN via PostgreSQL Announce Reply-To: david@fetter.org Date: Mon, 15 Nov 2021 20:16:03 +0000 Message-ID: <163700736335.11064.3531294968006022693@wrigleys.postgresql.org> X-Auto-Response-Suppress: All Auto-Submitted: auto-generated X-pglister-tags: pwn X-pglister-tagsig: 627b310e189af430cf8056c77a8c02057e35235ad5726c486ae4feed76a469e0 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --===============6840132456155053707== Content-Type: multipart/alternative; boundary="===============8457841827347768312==" MIME-Version: 1.0 --===============8457841827347768312== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable # PostgreSQL Weekly News - November 14, 2021 PostgreSQL 14.1, 13.5, 12.9, 11.14, 10.19, and 9.6.24 [released](https://www.postgresql.org/about/news/postgresql-141-135-129-111= 4-1019-and-9624-released-2349/). This is the final release in the 9.6 series, so put those upgrade plans in action if you haven't already. # PostgreSQL Product News Pgpool-II 4.3 beta1 a connection pooler and statement replication system for PostgreSQL, [released](https://www.pgpool.net/docs/43/en/html/release-4-3-0.html) Odyssey 1.2, a multi-threaded connection pooler for PostgreSQL, released. https://github.com/yandex/odyssey/releases pgbouncer 1.16.1, a connection pooler and more for PostgreSQL, [released](https://www.pgbouncer.org/2021/11/pgbouncer-1-16-1) # PostgreSQL Jobs for November [https://archives.postgresql.org/pgsql-jobs/2021-11/](https://archives.post= gresql.org/pgsql-jobs/2021-11/) # PostgreSQL in the News Planet PostgreSQL: [https://planet.postgresql.org/](https://planet.postgres= ql.org/) PostgreSQL Weekly News is brought to you this week by David Fetter Submit news and announcements by Sunday at 3:00pm PST8PDT to david@fetter.o= rg. # Applied Patches David Rowley pushed: - Fix incorrect hash equality operator bug in Memoize. In v14, because we d= on't have a field in RestrictInfo to cache both the left and right type's hash equality operator, we just restrict the scope of Memoize to only when the= left and right types of a RestrictInfo are the same. In master we add another field to RestrictInfo and cache both hash equality operators. Reported-b= y: Jaime Casanova Author: David Rowley Discussion: [https://postgr.es/m/20210929185544.GB24346%40ahch-to](https://postgr.es/= m/20210929185544.GB24346%40ahch-to) Backpatch-through: 14 [https://git.postgresql.org/pg/commitdiff/39a3105678a247bbfdc132cd95db5b5= 15b8cd7f6](https://git.postgresql.org/pg/commitdiff/39a3105678a247bbfdc132c= d95db5b515b8cd7f6) =20 Tom Lane pushed: - Reject extraneous data after SSL or GSS encryption handshake. The server collects up to a bufferload of data whenever it reads data from the client socket. When SSL or GSS encryption is requested during startup, any additional data received with the initial request message remained in the buffer, and would be treated as already-decrypted data once the encryption handshake completed. Thus, a man-in-the-middle with the ability to inject= data into the TCP connection could stuff some cleartext data into the start of= a supposedly encryption-protected database session. This could be abused to send faked SQL commands to the server, although that would only work if t= he server did not demand any authentication data. (However, a server relyin= g on SSL certificate authentication might well not do so.) To fix, throw a protocol-violation error if the internal buffer is not empty after the encryption handshake. Our thanks to Jacob Champion for reporting this problem. Security: CVE-2021-23214 [https://git.postgresql.org/pg/commitdiff/28e24125541545483093819efae9bca= 603441951](https://git.postgresql.org/pg/commitdiff/28e24125541545483093819= efae9bca603441951) =20 - libpq: reject extraneous data after SSL or GSS encryption handshake. libpq collects up to a bufferload of data whenever it reads data from the socke= t. When SSL or GSS encryption is requested during startup, any additional da= ta received with the server's yes-or-no reply remained in the buffer, and wo= uld be treated as already-decrypted data once the encryption handshake comple= ted. Thus, a man-in-the-middle with the ability to inject data into the TCP connection could stuff some cleartext data into the start of a supposedly encryption-protected database session. This could probably be abused to inject faked responses to the client's first few queries, although other details of libpq's behavior make that harder than it sounds. A different= line of attack is to exfiltrate the client's password, or other sensitive data= that might be sent early in the session. That has been shown to be possible w= ith a server vulnerable to CVE-2021-23214. To fix, throw a protocol-violation = error if the internal buffer is not empty after the encryption handshake. Our thanks to Jacob Champion for reporting this problem. Security: CVE-2021-= 23222 [https://git.postgresql.org/pg/commitdiff/160c0258802d10b0600d7671b1bbea5= 5d8e17d45](https://git.postgresql.org/pg/commitdiff/160c0258802d10b0600d767= 1b1bbea55d8e17d45) =20 - Fix incorrect format placeholder. Per buildfarm warnings. [https://git.postgresql.org/pg/commitdiff/b0cf5444f9a8d915b2e9b44790025f1= 7a7dc107f](https://git.postgresql.org/pg/commitdiff/b0cf5444f9a8d915b2e9b44= 790025f17a7dc107f) =20 - Fix instability in 026_overwrite_contrecord.pl test. We've seen intermitt= ent failures in this test on slower buildfarm machines, which I think can be explained by assuming that autovacuum emitted some additional WAL. Disab= le autovacuum to stabilize it. In passing, use stringwise not numeric compa= rison to compare WAL file names. Doesn't matter at present, but they are hex strings not decimal ... Discussion: [https://postgr.es/m/1372189.1636499287@sss.pgh.pa.us](https://postgr.es/= m/1372189.1636499287@sss.pgh.pa.us) [https://git.postgresql.org/pg/commitdiff/b66767b56b1cd082f3499a7e5a21b48= 0dd004f51](https://git.postgresql.org/pg/commitdiff/b66767b56b1cd082f3499a7= e5a21b480dd004f51) =20 - Doc: improve protocol spec for logical replication Type messages. protocol.sgml documented the layout for Type messages, but completely dro= pped the ball otherwise, failing to explain what they are, when they are sent,= or what they're good for. While at it, do a little copy-editing on the description of Relation messages. In passing, adjust the comment for apply_handle_type() to make it clearer that we choose not to do anything = when receiving a Type message, not that we think it has no use whatsoever. Per question from Stefen Hillman. Discussion: [https://postgr.es/m/CAPgW8pMknK5pup6=3DT4a_UG=3DCz80Rgp=3DKONqJmTdHfaZb0= RvnFg@mail.gmail.com](https://postgr.es/m/CAPgW8pMknK5pup6=3DT4a_UG=3DCz80R= gp=3DKONqJmTdHfaZb0RvnFg@mail.gmail.com) [https://git.postgresql.org/pg/commitdiff/c3b33698cf88550b017620f73b94b53= 029897f39](https://git.postgresql.org/pg/commitdiff/c3b33698cf88550b017620f= 73b94b53029897f39) =20 - Fall back to unsigned int, not int, for socklen_t. It's a coin toss which= of these is a better default assumption. However, of the machines we have in= the buildfarm, the only ones relying on the fallback socklen_t definition are ancient HPUX, and on that platform unsigned int is the right choice. Min= or tweak to ee3a1a5b6. Discussion: [https://postgr.es/m/1440792.1636558888@sss.pgh.pa.us](https://postgr.es/= m/1440792.1636558888@sss.pgh.pa.us) [https://git.postgresql.org/pg/commitdiff/01ec41a5fe4aa590dde18a2c551432a= a1925caea](https://git.postgresql.org/pg/commitdiff/01ec41a5fe4aa590dde18a2= c551432aa1925caea) =20 - postgres_fdw: suppress casts on constants in limited cases. When deparsin= g an expression of the form "remote_var OP constant", we'd normally apply a ca= st to the constant to make sure that the remote parser thinks it's of the same = type we do. However, doing so is often not necessary, and it causes problems = if the user has intentionally declared the local column as being of a differ= ent type than the remote column. A plausible use-case for that is using text= to represent a type that's an enum on the remote side. A comparison on such a column will get shipped as "var =3D 'foo'::text", which blows up on the r= emote side because there's no enum =3D text operator. But if we simply leave o= ff the explicit cast, the comparison will do exactly what the user wants. It's possible to do this without major risk of semantic problems, by relying o= n the longstanding parser heuristic that "if one operand of an operator is of t= ype unknown, while the other one has a known type, assume that the unknown op= erand is also of that type". Hence, this patch leaves off the cast only if (a)= the operator inputs have the same type locally; (b) the constant will print a= s a string literal or NULL, both of which are initially taken as type unknown= ; and (c) the non-Const input is a plain foreign Var. Rule (c) guarantees that= the remote parser will know the type of the non-Const input; moreover, it mea= ns that if this cast-omission does cause any semantic surprises, that can on= ly happen in cases where the local column has a different type than the remo= te column. That wasn't guaranteed to work anyway, and this patch should represent a net usability gain for such cases. One point that I (tgl) re= main slightly uncomfortable with is that we will ignore an implicit RelabelType when deciding if the non-Const input is a plain Var. That makes it a lit= tle squishy to argue that the remote should resolve the Const as being of the= same type as its Var, because then our Const is not the same type as our Var. However, if we don't do that, then this hack won't work as desired if the= user chooses to use varchar rather than text to represent some remote column. = That seems useful, so do it like this for now. We might have to give up the RelabelType-ignoring bit if any problems surface. Dian Fay, with review = and kibitzing by me Discussion: [https://postgr.es/m/C9LU294V7K4F.34LRRDU449O45@lamia](https://postgr.es/= m/C9LU294V7K4F.34LRRDU449O45@lamia) [https://git.postgresql.org/pg/commitdiff/f8abb0f5e114d8c309239f0faa277b9= 7f696d829](https://git.postgresql.org/pg/commitdiff/f8abb0f5e114d8c309239f0= faa277b97f696d829) =20 - Make psql's \password default to CURRENT_USER, not PQuser(conn). The documentation says plainly that \password acts on "the current user" by default. What it actually acted on, or tried to, was the username used t= o log into the current session. This is not the same thing if one has since do= ne SET ROLE or SET SESSION AUTHENTICATION. Aside from the possible surprise factor, it's quite likely that the current role doesn't have permissions = to set the password of the original role. To fix, use "SELECT CURRENT_USER"= to get the role name to act on. (This syntax works with servers at least bac= k to 7.0.) Also, in hopes of reducing confusion, include the role name that w= ill be acted on in the password prompt. The discrepancy from the documentati= on makes this a bug, so back-patch to all supported branches. Patch by me; thanks to Nathan Bossart for review. Discussion: [https://postgr.es/m/747443.1635536754@sss.pgh.pa.us](https://postgr.es/m= /747443.1635536754@sss.pgh.pa.us) [https://git.postgresql.org/pg/commitdiff/d6eb5a0c258d3da5471814bcc6ed649= 8129fee16](https://git.postgresql.org/pg/commitdiff/d6eb5a0c258d3da5471814b= cc6ed6498129fee16) =20 Robert Haas pushed: - Minimal fix for unterminated tar archive problem. Commit 23a1c6578c87fca0e361c4f5f9a07df5ae1f9858 improved pg_basebackup's ability= to parse tar archives, but also arranged to parse them only when we need to = make some modification to the contents of the archive. That's a problem, becau= se the server doesn't actually terminate tar archives. When the new parsing = logic was engaged, pg_basebackup would properly terminate the tar file, but whe= n it was skipped, pg_basebackup would just write whatever it got from the serv= er, meaning that the terminator was missing. Most versions of tar are willin= g to overlook the missing terminator, but the AIX buildfarm animals were not. = Fix by inventing a new kind of bbstreamer that just blindly adds a terminator= , and using it whenever we don't parse the tar archive. Discussion: [http://postgr.es/m/CA+TgmoZbNzsWwM4BE5Jb_qHncY817DYZwGf+2-7hkMQ27ZwsMQ@m= ail.gmail.com](http://postgr.es/m/CA+TgmoZbNzsWwM4BE5Jb_qHncY817DYZwGf+2-7h= kMQ27ZwsMQ@mail.gmail.com) [https://git.postgresql.org/pg/commitdiff/57b5a9646d97a3e8a5b6b6d86b375cc= 8da6ac85c](https://git.postgresql.org/pg/commitdiff/57b5a9646d97a3e8a5b6b6d= 86b375cc8da6ac85c) =20 - Have the server properly terminate tar archives. Earlier versions of PostgreSQL featured a version of pg_basebackup that wanted to edit tar archives but was too dumb to parse them properly. The server made things easier for the client by failing to add the two blocks of zero bytes that ought to end a tar file, leaving it up to the client to do that. But sin= ce commit 23a1c6578c87fca0e361c4f5f9a07df5ae1f9858, we don't need this hack = any more, because pg_basebackup is now smarter and can parse tar files even if they are properly terminated! So change the server to always properly terminate the tar files. Older versions of pg_basebackup can't talk to new servers anyway, so there's no compatibility break. On the pg_basebackup = side, we see still need to add the terminating zero bytes if we're talking to an older server, but not when the server is v15+. Hopefully at some point we= 'll be able to remove some of this compatibility cruft, but it seems best to = hang on to it for now. In passing, add a file header comment to bbstreamer_ta= r.c, to make it clearer what's going on here. Discussion: [http://postgr.es/m/CA+TgmoZbNzsWwM4BE5Jb_qHncY817DYZwGf+2-7hkMQ27ZwsMQ@m= ail.gmail.com](http://postgr.es/m/CA+TgmoZbNzsWwM4BE5Jb_qHncY817DYZwGf+2-7h= kMQ27ZwsMQ@mail.gmail.com) [https://git.postgresql.org/pg/commitdiff/5a1007a5088cd6ddf892f7422ea8dba= ef362372f](https://git.postgresql.org/pg/commitdiff/5a1007a5088cd6ddf892f74= 22ea8dbaef362372f) =20 - More cleanup of 'ThisTimeLineID'. In XLogCtlData, rename the structure me= mber ThisTimeLineID to InsertTimeLineID and update the comments to make clear = that it's only expected to be set after recovery is complete. In StartupXLOG, replace the local variables ThisTimeLineID and PrevTimeLineID with new lo= cal variables replayTLI and newTLI. In the old scheme, ThisTimeLineID was the replay TLI until we created a new timeline, and after that the replay TLI= was in PrevTimeLineID. Now, replayTLI is the TLI from which we last replayed = WAL throughout the entire function, and newTLI is either that, or the new tim= eline created upon promotion. Remove some misleading comments from the comment block just above where recoveryTargetTimeLineGoal and friends are declare= d. It's become incorrect, not only because ThisTimeLineID as a variable is n= ow gone, but also because the rmgr code does not care about ThisTimeLineID a= nd has not since what used to be the TLI field in the page header was repurp= osed to store the page checksum. Add a comment GetFlushRecPtr that it's only supposed to be used in normal running, and an assertion to verify that th= is is so. Per some ideas from Michael Paquier and some of my own. Review by Mi= chael Paquier also. Discussion: [http://postgr.es/m/CA+TgmoY1a2d1AnVR3tJcKmGGkhj7GGrwiNwjtKr21dxOuLBzCQ@m= ail.gmail.com](http://postgr.es/m/CA+TgmoY1a2d1AnVR3tJcKmGGkhj7GGrwiNwjtKr2= 1dxOuLBzCQ@mail.gmail.com) [https://git.postgresql.org/pg/commitdiff/a27048cbcb582056bfbf15aa2f898b4= a3ec74304](https://git.postgresql.org/pg/commitdiff/a27048cbcb582056bfbf15a= a2f898b4a3ec74304) =20 - Fix thinko in assertion in basebackup.c. Commit 5a1007a5088cd6ddf892f7422ea8dbaef362372f tried to introduce an assertion = that the block size was at least twice the size of a tar block, but I got the = math wrong. My error was reported to me off-list. [https://git.postgresql.org/pg/commitdiff/10eae82b27cebbb9586cda8baf8e322= 6496891d0](https://git.postgresql.org/pg/commitdiff/10eae82b27cebbb9586cda8= baf8e3226496891d0) =20 - Improve performance of pgarch_readyXlog() with many status files. Present= ly, the archive_status directory was scanned for each file to archive. When = there are many status files, say because archive_command has been failing for a= long time, these directory scans can get very slow. With this change, the arc= hiver remembers several files to archive during each directory scan, speeding t= hings up. To ensure timeline history files are archived as quickly as possible, XLogArchiveNotify() forces the archiver to do a new directory scan as soo= n as the .ready file for one is created. Nathan Bossart, per a long discussion involving many people. It is not clear to me exactly who out of all those people reviewed this particular patch. Discussion: [http://postgr.es/m/CA+TgmobhAbs2yabTuTRkJTq_kkC80-+jw=3DpfpypdOJ7+gAbQbw= @mail.gmail.com](http://postgr.es/m/CA+TgmobhAbs2yabTuTRkJTq_kkC80-+jw=3Dpf= pypdOJ7+gAbQbw@mail.gmail.com) Discussion: [http://postgr.es/m/620F3CE1-0255-4D66-9D87-0EADE866985A@amazon.com](http= ://postgr.es/m/620F3CE1-0255-4D66-9D87-0EADE866985A@amazon.com) [https://git.postgresql.org/pg/commitdiff/beb4e9ba1652a04f66ff20261444d06= f678c0b2d](https://git.postgresql.org/pg/commitdiff/beb4e9ba1652a04f66ff202= 61444d06f678c0b2d) =20 Amit Kapila pushed: - Rename some enums to use TABLE instead of REL. Commit 5a2832465f introduc= ed some enums to represent all tables in schema publications and used REL in their names. Use TABLE instead of REL in those enums to avoid confusion w= ith other objects like SEQUENCES that can be part of a publication in the fut= ure. In the passing, (a) Change one of the newly introduced error messages to = make it consistent for Create and Alter commands, (b) add missing alias in one= of the SQL Statements that is used to print publications associated with the table. Reported-by: Tomas Vondra, Peter Smith Author: Vignesh C Reviewed= -by: Hou Zhijie, Peter Smith Discussion: [https://www.postgresql.org/message-id/CALDaNm0OANxuJ6RXqwZsM1MSY4s19nuH3= 734j4a72etDwvBETQ%40mail.gmail.com](https://www.postgresql.org/message-id/C= ALDaNm0OANxuJ6RXqwZsM1MSY4s19nuH3734j4a72etDwvBETQ%40mail.gmail.com) [https://git.postgresql.org/pg/commitdiff/b3812d0b9bcf00e8478186fc287940e= 17912248a](https://git.postgresql.org/pg/commitdiff/b3812d0b9bcf00e8478186f= c287940e17912248a) =20 Fujii Masao pushed: - doc: Add index entries for pg_stat_statements configuration parameters. Author: Ken Kato Reviewed-by: Julien Rouhaud, Fujii Masao Discussion: [https://postgr.es/m/699cfd8170178db087e54c954b21ece4@oss.nttdata.com](ht= tps://postgr.es/m/699cfd8170178db087e54c954b21ece4@oss.nttdata.com) [https://git.postgresql.org/pg/commitdiff/ec21779a5847ed89fab19431abbdba7= 94d4a998e](https://git.postgresql.org/pg/commitdiff/ec21779a5847ed89fab1943= 1abbdba794d4a998e) =20 Micha=C3=ABl Paquier pushed: - Make some comments use the term "ProcSignal" for consistency. The surroun= dings in procsignal.c prefer using "ProcSignal" rather than "procsignal". Auth= or: Bharath Rupireddy Discussion: [https://postgr.es/m/CALj2ACX99ghPmm1M_O4r4g+YsXFjCn=3DqF7PeDXntLwMpht_Gd= g@mail.gmail.com](https://postgr.es/m/CALj2ACX99ghPmm1M_O4r4g+YsXFjCn=3DqF7= PeDXntLwMpht_Gdg@mail.gmail.com) [https://git.postgresql.org/pg/commitdiff/4cd046c203bbca2955182f78eabc06e= 831ffdbb1](https://git.postgresql.org/pg/commitdiff/4cd046c203bbca2955182f7= 8eabc06e831ffdbb1) =20 - Improve error messages for some callers of XLogReadRecord(). A couple of = code paths related to logical decoding (WAL sender, slot advancing, etc.) use XLogReadRecord(), feeding on error messages generated by walreader.c on a failure. All those messages have no context, making it harder to spot fr= om where an error could come even if these should not happen. All the other callers of XLogReadRecord() do that already. Reviewed-by: Kyotaro Horigu= chi Discussion: [https://postgr.es/m/YYnTH6OyOwQcAdkw@paquier.xyz](https://postgr.es/m/YY= nTH6OyOwQcAdkw@paquier.xyz) [https://git.postgresql.org/pg/commitdiff/c9c401a5e13accc4a3a775e3feeabdc= 5940c9178](https://git.postgresql.org/pg/commitdiff/c9c401a5e13accc4a3a775e= 3feeabdc5940c9178) =20 - Clean up compilation warnings coming from PL/Perl with clang-12~. clang-1= 2 has introduced -Wcompound-token-split-by-macro, that is causing a large amoun= t of warnings when building PL/Perl because of its interactions with upstream = Perl. This commit adds one -Wno to CFLAGS at ./configure time if the flag is supported by the compiler to silence all those warnings. Upstream perl h= as fixed this issue, but it is going to take some time before this is spread across the buildfarm, and we have noticed that some animals would be usef= ul with an extra -Werror to help with the detection of incorrect placeholders (see b0cf544), dangomushi being one. Reviewed-by: Tom Lane Discussion: [https://postgr.es/m/YYr3qYa/R3Gw+Sbg@paquier.xyz](https://postgr.es/m/YY= r3qYa/R3Gw+Sbg@paquier.xyz) Backpatch-through: 10 [https://git.postgresql.org/pg/commitdiff/9ff47ea414c4e6ace347fc4e59866e3= 8b9bbceaf](https://git.postgresql.org/pg/commitdiff/9ff47ea414c4e6ace347fc4= e59866e38b9bbceaf) =20 - Fix buffer overrun in unicode string normalization with empty input. PostgreSQL 13 and newer versions are directly impacted by that through th= e SQL function normalize(), which would cause a call of this function to write = one byte past its allocation if using in input an empty string after recompos= ing the string with NFC and NFKC. Older versions (v10~v12) are not directly affected by this problem as the only code path using normalization is SAS= Lprep in SCRAM authentication that forbids the case of an empty string, but let= 's make the code more robust anyway there so as any out-of-core callers of t= his function are covered. The solution chosen to fix this issue is simple, w= ith the addition of a fast-exit path if the decomposed string is found as emp= ty. This would only happen for an empty string as at its lowest level a codep= oint would be decomposed as itself if it has no entry in the decomposition tab= le or if it has a decomposition size of 0. Some tests are added to cover this = issue in v13~. Note that an empty string has always been considered as normali= zed (grammar "IS NF[K]{C,D} NORMALIZED", through the SQL function is_normaliz= ed()) for all the operations allowed (NFC, NFD, NFKC and NFKD) since this featu= re has been introduced as of 2991ac5. This behavior is unchanged but some t= ests are added in v13~ to check after that. I have also checked "make normalization-check" in src/common/unicode/, while on it (works in 13~, a= nd breaks in older stable branches independently of this commit). The relea= se notes should just mention this commit for v13~. Reported-by: Matthijs va= n der Vleuten Discussion: [https://postgr.es/m/17277-0c527a373794e802@postgresql.org](https://postg= r.es/m/17277-0c527a373794e802@postgresql.org) Backpatch-through: 10 [https://git.postgresql.org/pg/commitdiff/098c134556664d37b78ae87853a82f4= a9d23a2c8](https://git.postgresql.org/pg/commitdiff/098c134556664d37b78ae87= 853a82f4a9d23a2c8) =20 - Fix memory overrun when querying pg_stat_slru. pg_stat_get_slru() in pgstatfuncs.c would point to one element after the end of the array PgStat_SLRUStats when finishing to scan its entries. This had no direct consequences as no data from the extra memory area was read, but static analyzers would rightfully complain here. So let's be clean. While on i= t, this adds one regression test in the area reserved for system views. Reported-by: Alexander Kozhemyakin, via AddressSanitizer Author: Kyotaro Horiguchi Discussion: [https://postgr.es/m/17280-37da556e86032070@postgresql.org](https://postg= r.es/m/17280-37da556e86032070@postgresql.org) Backpatch-through: 13 [https://git.postgresql.org/pg/commitdiff/a45ed975c58fde7303eeae488b313bf= 0314383f7](https://git.postgresql.org/pg/commitdiff/a45ed975c58fde7303eeae4= 88b313bf0314383f7) =20 Peter Eisentraut pushed: - Remove check for accept() argument types. This check was used to accommod= ate a staggering variety in particular in the type of the third argument of accept(). This is no longer of concern on currently supported systems. = We can just use socklen_t in the code and put in a simple check that substit= utes int for socklen_t if it's missing, to cover the few stragglers. Reviewed= -by: Andres Freund Discussion: [https://www.postgresql.org/message-id/3538f4c4-1886-64f2-dcff-aaad8267fb= 82@enterprisedb.com](https://www.postgresql.org/message-id/3538f4c4-1886-64= f2-dcff-aaad8267fb82@enterprisedb.com) [https://git.postgresql.org/pg/commitdiff/ee3a1a5b636b69dde33d68c428dd56b= 3389a4538](https://git.postgresql.org/pg/commitdiff/ee3a1a5b636b69dde33d68c= 428dd56b3389a4538) =20 - Fix incorrect format placeholders. [https://git.postgresql.org/pg/commitdiff/733e0391536dad99a2677ca5e192918= 54da5730f](https://git.postgresql.org/pg/commitdiff/733e0391536dad99a2677ca= 5e19291854da5730f) =20 - doc: Add referential actions to CREATE/ALTER TABLE synopsis. The general constraint synopsis references "referential_action", but this was not fur= ther defined in the synopsis section. Compared to the level of detail that the synopsis gives to other subclauses, this should surely be there. extract= ed from a patch by Paul Martinez Discussion: [https://www.postgresql.org/message-id/flat/CACqFVBZQyMYJV=3DnjbSMxf+rbDH= px=3DW=3DB7AEaMKn8dWn9OZJY7w@mail.gmail.com](https://www.postgresql.org/mes= sage-id/flat/CACqFVBZQyMYJV=3DnjbSMxf+rbDHpx=3DW=3DB7AEaMKn8dWn9OZJY7w@mail= .gmail.com) [https://git.postgresql.org/pg/commitdiff/db9f287711ac49d9799f93f664d6d10= 1ff8f5891](https://git.postgresql.org/pg/commitdiff/db9f287711ac49d9799f93f= 664d6d101ff8f5891) =20 Jeff Davis pushed: - Add pg_checkpointer predefined role for CHECKPOINT command. Any user with= the privileges of pg_checkpointer can issue a CHECKPOINT command. Reviewed-b= y: Stephen Frost Discussion: [https://postgr.es/m/67a1d667e8ec228b5e07f232184c80348c5d93f4.camel%40j-d= avis.com](https://postgr.es/m/67a1d667e8ec228b5e07f232184c80348c5d93f4.came= l%40j-davis.com) [https://git.postgresql.org/pg/commitdiff/4168a4745492cd54a0ffffc271b4525= 25ef4dc60](https://git.postgresql.org/pg/commitdiff/4168a4745492cd54a0ffffc= 271b452525ef4dc60) =20 =C3=81lvaro Herrera pushed: - Restore lock level to set vacuum flags. Commit 27838981be9d mistakenly re= duced the lock level from exclusive to shared that is acquired to set PGPROC->statusFlags; this was reverted by dcfff74fb166, but failed to do = so in one spot. Fix it. Backpatch to 14. Noted by Andres Freund. Discussion: [https://postgr.es/m/20211111020724.ggsfhcq3krq5r4hb@alap3.anarazel.de](h= ttps://postgr.es/m/20211111020724.ggsfhcq3krq5r4hb@alap3.anarazel.de) [https://git.postgresql.org/pg/commitdiff/0726c764bc4ec337a0216a546ce41c7= 58d81600d](https://git.postgresql.org/pg/commitdiff/0726c764bc4ec337a0216a5= 46ce41c758d81600d) =20 Peter Geoghegan pushed: - Update another obsolete reference in vacuumlazy.c. Addresses an oversight= in commit 7ab96cf6. [https://git.postgresql.org/pg/commitdiff/eb9baef8e92adf81c6adbe44f1d6787= 8d850bff7](https://git.postgresql.org/pg/commitdiff/eb9baef8e92adf81c6adbe4= 4f1d67878d850bff7) =20 - Update heap_page_prune() free space map comments. It is up to the heap_page_prune() caller to decide what to do about updating the FSM for a page following pruning. Update old comments that address what we might w= ant to do as if it was the responsibility of heap_page_prune() itself. heap_page_prune() doesn't have enough high-level context to make a sensib= le choice. [https://git.postgresql.org/pg/commitdiff/42f9427aa98a2245d29737e0f3b8aaf= 39a7f57ec](https://git.postgresql.org/pg/commitdiff/42f9427aa98a2245d29737e= 0f3b8aaf39a7f57ec) =20 - Explain pruning pgstats accounting subtleties. Add a comment explaining w= hy the pgstats accounting used during opportunistic heap pruning operations = (to maintain the current number of dead tuples in the relation) needs to compensate by subtracting away the number of new LP_DEAD items. This is needed so it can avoid completely forgetting about tuples that become LP_= DEAD items during pruning -- they should still count. It seems more natural to discuss this issue at the only relevant call site (opportunistic pruning), since the same issue does not apply to the only other caller (the VACUUM = call site). Move everything there too. Author: Peter Geoghegan Discussion: [https://postgr.es/m/CAH2-Wzm7f+A6ej650gi_ifTgbhsadVW5cujAL3punpupHff5Yg@= mail.gmail.com](https://postgr.es/m/CAH2-Wzm7f+A6ej650gi_ifTgbhsadVW5cujAL3= punpupHff5Yg@mail.gmail.com) [https://git.postgresql.org/pg/commitdiff/b0f7425ec2445678f32381de8bd3174= d3cc2167e](https://git.postgresql.org/pg/commitdiff/b0f7425ec2445678f32381d= e8bd3174d3cc2167e) =20 Noah Misch pushed: - Report any XLogReadRecord() error in XlogReadTwoPhaseData(). Buildfarm me= mbers kittiwake and tadarida have witnessed errors at this site. The site disc= arded key facts. Back-patch to v10 (all supported versions). Reviewed by Mich= ael Paquier and Tom Lane. Discussion: [https://postgr.es/m/20211107013157.GB790288@rfd.leadboat.com](https://po= stgr.es/m/20211107013157.GB790288@rfd.leadboat.com) [https://git.postgresql.org/pg/commitdiff/335474691054a74d771f0e7c24d25e8= 00e3a37b6](https://git.postgresql.org/pg/commitdiff/335474691054a74d771f0e7= c24d25e800e3a37b6) =20 Andrew Dunstan pushed: - Report found versions of required perl modules. Configure tests for the presence of perl modules required for TAP tests, and that they meet speci= fied minimum version requirements. This patch makes it report the version of t= he module that's actually found rather than just an 'ok' message. This will = help in deciding if we can upgrade minimum requirements for these modules. Discussion: [https://postgr.es/m/f5e1d308-4e33-37a7-bdf1-f6e0c75119de@dunslane.net](h= ttps://postgr.es/m/f5e1d308-4e33-37a7-bdf1-f6e0c75119de@dunslane.net) [https://git.postgresql.org/pg/commitdiff/1593998ae858902e805eb0f8bf3b019= 399044471](https://git.postgresql.org/pg/commitdiff/1593998ae858902e805eb0f= 8bf3b019399044471) =20 Daniel Gustafsson pushed: - Document PG_TEST_NOCLEAN in TAP test README. Commit 90627cf98 added suppo= rt for retaining the data directory even on successful tests, but failed to document the environment variable which controls retention. This adds a s= mall note to the TAP test README about PG_TEST_NOCLEAN which when set skips removing the data directories from successful tests. Reviewed-by: Tom La= ne Discussion: [https://postgr.es/m/2B02C1B3-3F41-4E14-92B9-005D83623A0B@yesql.se](https= ://postgr.es/m/2B02C1B3-3F41-4E14-92B9-005D83623A0B@yesql.se) [https://git.postgresql.org/pg/commitdiff/05d8785af2a192d436df5b7734aacb4= e0bab5da8](https://git.postgresql.org/pg/commitdiff/05d8785af2a192d436df5b7= 734aacb4e0bab5da8) --===============8457841827347768312== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable PostgreSQL Weekly News - November 14, 2021
 

PostgreSQL Weekly News - November 14, 2021

PostgreSQL Weekly News - November 14, 2021

PostgreSQL 14.1, 13.5, 12.9, 11.14, 10.19, = and 9.6.24 released. This is the final release in the 9.6 series, so put those upgrade plans in action if you haven't already.

PostgreSQL Product News

Pgpool-II 4.3 beta1 a connection pooler and= statement replication system for PostgreSQL, released

Odyssey 1.2, a multi-threaded connection po= oler for PostgreSQL, released. https://github.com/yandex/odyssey/releases

pgbouncer 1.16.1, a connection pooler and m= ore for PostgreSQL, released

PostgreSQL Jobs for November

h= ttps://archives.postgresql.org/pgsql-jobs/2021-11/

PostgreSQL in the News

Planet PostgreSQL: htt= ps://planet.postgresql.org/

PostgreSQL Weekly News is brought to you th= is week by David Fetter

Submit news and announcements by Sunday at = 3:00pm PST8PDT to david@fetter.org.

Applied Patches

David Rowley pushed:

Tom Lane pushed:

  • Reject extraneous data after SSL or GSS enc= ryption handshake. The server collects up to a bufferload of data whenever it reads data from the client socket. When SSL or GSS encryption is requested during startup, any additional data received with the initial request message remained in the buffer, and would be treated as already-decrypted data once the encryption handshake completed. Thus, a man-in-the-middle with the ability to inject= data into the TCP connection could stuff some cleartext data into the start of= a supposedly encryption-protected database session. This could be abused to send faked SQL commands to the server, although that would only work if t= he server did not demand any authentication data. (However, a server relyin= g on SSL certificate authentication might well not do so.) To fix, throw a protocol-violation error if the internal buffer is not empty after the encryption handshake. Our thanks to Jacob Champion for reporting this problem. Security: CVE-2021-23214 h= ttps://git.postgresql.org/pg/commitdiff/28e24125541545483093819efae9bca6034= 41951

  • libpq: reject extraneous data after SSL or = GSS encryption handshake. libpq collects up to a bufferload of data whenever it reads data from the socke= t. When SSL or GSS encryption is requested during startup, any additional da= ta received with the server's yes-or-no reply remained in the buffer, and wo= uld be treated as already-decrypted data once the encryption handshake comple= ted. Thus, a man-in-the-middle with the ability to inject data into the TCP connection could stuff some cleartext data into the start of a supposedly encryption-protected database session. This could probably be abused to inject faked responses to the client's first few queries, although other details of libpq's behavior make that harder than it sounds. A different= line of attack is to exfiltrate the client's password, or other sensitive data= that might be sent early in the session. That has been shown to be possible w= ith a server vulnerable to CVE-2021-23214. To fix, throw a protocol-violation = error if the internal buffer is not empty after the encryption handshake. Our thanks to Jacob Champion for reporting this problem. Security: CVE-2021-= 23222 h= ttps://git.postgresql.org/pg/commitdiff/160c0258802d10b0600d7671b1bbea55d8e= 17d45

  • Fix incorrect format placeholder. Per build= farm warnings. h= ttps://git.postgresql.org/pg/commitdiff/b0cf5444f9a8d915b2e9b44790025f17a7d= c107f

  • Fix instability in 026_overwrite_contrecord= .pl test. We've seen intermittent failures in this test on slower buildfarm machines, which I think can be explained by assuming that autovacuum emitted some additional WAL. Disab= le autovacuum to stabilize it. In passing, use stringwise not numeric compa= rison to compare WAL file names. Doesn't matter at present, but they are hex strings not decimal ... Discussion: https://postgr.es/m/1372189.16= 36499287@sss.pgh.pa.us htt= ps://git.postgresql.org/pg/commitdiff/b66767b56b1cd082f3499a7e5a21b480dd004= f51

  • Doc: improve protocol spec for logical repl= ication Type messages. protocol.sgml documented the layout for Type messages, but completely dro= pped the ball otherwise, failing to explain what they are, when they are sent,= or what they're good for. While at it, do a little copy-editing on the description of Relation messages. In passing, adjust the comment for apply_handle_type() to make it clearer that we choose not to do anything = when receiving a Type message, not that we think it has no use whatsoever. Per question from Stefen Hillman. Discussion: https://postgr.es/m/CAPgW8pMknK5pup6=3DT4a_UG=3DCz80Rgp=3DKONqJmT= dHfaZb0RvnFg@mail.gmail.com htt= ps://git.postgresql.org/pg/commitdiff/c3b33698cf88550b017620f73b94b53029897= f39

  • Fall back to unsigned int, not int, for soc= klen_t. It's a coin toss which of these is a better default assumption. However, of the machines we have in= the buildfarm, the only ones relying on the fallback socklen_t definition are ancient HPUX, and on that platform unsigned int is the right choice. Min= or tweak to ee3a1a5b6. Discussion: https://postgr.es/m/1440792.16= 36558888@sss.pgh.pa.us htt= ps://git.postgresql.org/pg/commitdiff/01ec41a5fe4aa590dde18a2c551432aa1925c= aea

  • postgres_fdw: suppress casts on constants i= n limited cases. When deparsing an expression of the form "remote_var OP constant", we'd normally apply a ca= st to the constant to make sure that the remote parser thinks it's of the same = type we do. However, doing so is often not necessary, and it causes problems = if the user has intentionally declared the local column as being of a differ= ent type than the remote column. A plausible use-case for that is using text= to represent a type that's an enum on the remote side. A comparison on such a column will get shipped as "var =3D 'foo'::text", which blows up on the r= emote side because there's no enum =3D text operator. But if we simply leave o= ff the explicit cast, the comparison will do exactly what the user wants. It's possible to do this without major risk of semantic problems, by relying o= n the longstanding parser heuristic that "if one operand of an operator is of t= ype unknown, while the other one has a known type, assume that the unknown op= erand is also of that type". Hence, this patch leaves off the cast only if (a)= the operator inputs have the same type locally; (b) the constant will print a= s a string literal or NULL, both of which are initially taken as type unknown= ; and (c) the non-Const input is a plain foreign Var. Rule (c) guarantees that= the remote parser will know the type of the non-Const input; moreover, it mea= ns that if this cast-omission does cause any semantic surprises, that can on= ly happen in cases where the local column has a different type than the remo= te column. That wasn't guaranteed to work anyway, and this patch should represent a net usability gain for such cases. One point that I (tgl) re= main slightly uncomfortable with is that we will ignore an implicit RelabelType when deciding if the non-Const input is a plain Var. That makes it a lit= tle squishy to argue that the remote should resolve the Const as being of the= same type as its Var, because then our Const is not the same type as our Var. However, if we don't do that, then this hack won't work as desired if the= user chooses to use varchar rather than text to represent some remote column. = That seems useful, so do it like this for now. We might have to give up the RelabelType-ignoring bit if any problems surface. Dian Fay, with review = and kibitzing by me Discussion: https://postgr.es/m/C9LU294V7K= 4F.34LRRDU449O45@lamia htt= ps://git.postgresql.org/pg/commitdiff/f8abb0f5e114d8c309239f0faa277b97f696d= 829

  • Make psql's \password default to CURRENT_US= ER, not PQuser(conn). The documentation says plainly that \password acts on "the current user" by default. What it actually acted on, or tried to, was the username used t= o log into the current session. This is not the same thing if one has since do= ne SET ROLE or SET SESSION AUTHENTICATION. Aside from the possible surprise factor, it's quite likely that the current role doesn't have permissions = to set the password of the original role. To fix, use "SELECT CURRENT_USER"= to get the role name to act on. (This syntax works with servers at least bac= k to 7.0.) Also, in hopes of reducing confusion, include the role name that w= ill be acted on in the password prompt. The discrepancy from the documentati= on makes this a bug, so back-patch to all supported branches. Patch by me; thanks to Nathan Bossart for review. Discussion: https://postgr.es/m/747443.1635= 536754@sss.pgh.pa.us htt= ps://git.postgresql.org/pg/commitdiff/d6eb5a0c258d3da5471814bcc6ed6498129fe= e16

Robert Haas pushed:

  • Minimal fix for unterminated tar archive pr= oblem. Commit 23a1c6578c87fca0e361c4f5f9a07df5ae1f9858 improved pg_basebackup's ability= to parse tar archives, but also arranged to parse them only when we need to = make some modification to the contents of the archive. That's a problem, becau= se the server doesn't actually terminate tar archives. When the new parsing = logic was engaged, pg_basebackup would properly terminate the tar file, but whe= n it was skipped, pg_basebackup would just write whatever it got from the serv= er, meaning that the terminator was missing. Most versions of tar are willin= g to overlook the missing terminator, but the AIX buildfarm animals were not. = Fix by inventing a new kind of bbstreamer that just blindly adds a terminator= , and using it whenever we don't parse the tar archive. Discussion: http://postgr.es/m/CA+TgmoZbNzsWwM4BE5Jb_qHncY817DYZwGf+2-7hkMQ27ZwsMQ@m= ail.gmail.com htt= ps://git.postgresql.org/pg/commitdiff/57b5a9646d97a3e8a5b6b6d86b375cc8da6ac= 85c

  • Have the server properly terminate tar arch= ives. Earlier versions of PostgreSQL featured a version of pg_basebackup that wanted to edit tar archives but was too dumb to parse them properly. The server made things easier for the client by failing to add the two blocks of zero bytes that ought to end a tar file, leaving it up to the client to do that. But sin= ce commit 23a1c6578c87fca0e361c4f5f9a07df5ae1f9858, we don't need this hack = any more, because pg_basebackup is now smarter and can parse tar files even if they are properly terminated! So change the server to always properly terminate the tar files. Older versions of pg_basebackup can't talk to new servers anyway, so there's no compatibility break. On the pg_basebackup = side, we see still need to add the terminating zero bytes if we're talking to an older server, but not when the server is v15+. Hopefully at some point we= 'll be able to remove some of this compatibility cruft, but it seems best to = hang on to it for now. In passing, add a file header comment to bbstreamer_ta= r.c, to make it clearer what's going on here. Discussion: http://postgr.es/m/CA+TgmoZbNzsWwM4BE5Jb_qHncY817DYZwGf+2-7hkMQ27ZwsMQ@m= ail.gmail.com htt= ps://git.postgresql.org/pg/commitdiff/5a1007a5088cd6ddf892f7422ea8dbaef3623= 72f

  • More cleanup of 'ThisTimeLineID'. In XLogCt= lData, rename the structure member ThisTimeLineID to InsertTimeLineID and update the comments to make clear = that it's only expected to be set after recovery is complete. In StartupXLOG, replace the local variables ThisTimeLineID and PrevTimeLineID with new lo= cal variables replayTLI and newTLI. In the old scheme, ThisTimeLineID was the replay TLI until we created a new timeline, and after that the replay TLI= was in PrevTimeLineID. Now, replayTLI is the TLI from which we last replayed = WAL throughout the entire function, and newTLI is either that, or the new tim= eline created upon promotion. Remove some misleading comments from the comment block just above where recoveryTargetTimeLineGoal and friends are declare= d. It's become incorrect, not only because ThisTimeLineID as a variable is n= ow gone, but also because the rmgr code does not care about ThisTimeLineID a= nd has not since what used to be the TLI field in the page header was repurp= osed to store the page checksum. Add a comment GetFlushRecPtr that it's only supposed to be used in normal running, and an assertion to verify that th= is is so. Per some ideas from Michael Paquier and some of my own. Review by Mi= chael Paquier also. Discussion: http://postgr.es/m/CA+TgmoY1a2d1AnVR3tJcKmGGkhj7GGrwiNwjtKr21dxOuLBzCQ@m= ail.gmail.com htt= ps://git.postgresql.org/pg/commitdiff/a27048cbcb582056bfbf15aa2f898b4a3ec74= 304

  • Fix thinko in assertion in basebackup.c. Co= mmit 5a1007a5088cd6ddf892f7422ea8dbaef362372f tried to introduce an assertion = that the block size was at least twice the size of a tar block, but I got the = math wrong. My error was reported to me off-list. h= ttps://git.postgresql.org/pg/commitdiff/10eae82b27cebbb9586cda8baf8e3226496= 891d0

  • Improve performance of pgarch_readyXlog() w= ith many status files. Presently, the archive_status directory was scanned for each file to archive. When = there are many status files, say because archive_command has been failing for a= long time, these directory scans can get very slow. With this change, the arc= hiver remembers several files to archive during each directory scan, speeding t= hings up. To ensure timeline history files are archived as quickly as possible, XLogArchiveNotify() forces the archiver to do a new directory scan as soo= n as the .ready file for one is created. Nathan Bossart, per a long discussion involving many people. It is not clear to me exactly who out of all those people reviewed this particular patch. Discussion: http://postgr.es/m/CA+TgmobhAbs2yabTuTRkJTq_kkC80-+jw=3DpfpypdOJ7+gAbQ= bw@mail.gmail.com Discussion: http://postgr.es= /m/620F3CE1-0255-4D66-9D87-0EADE866985A@amazon.com htt= ps://git.postgresql.org/pg/commitdiff/beb4e9ba1652a04f66ff20261444d06f678c0= b2d

Amit Kapila pushed:

Fujii Masao pushed:

Micha=C3=ABl Paquier pushed:

  • Make some comments use the term "ProcSignal= " for consistency. The surroundings in procsignal.c prefer using "ProcSignal" rather than "procsignal". Auth= or: Bharath Rupireddy Discussion: https://postgr.es/m/CALj2ACX99ghPmm1M_O4r4g+YsXFjCn=3DqF7PeDXntLwMpht= _Gdg@mail.gmail.com htt= ps://git.postgresql.org/pg/commitdiff/4cd046c203bbca2955182f78eabc06e831ffd= bb1

  • Improve error messages for some callers of = XLogReadRecord(). A couple of code paths related to logical decoding (WAL sender, slot advancing, etc.) use XLogReadRecord(), feeding on error messages generated by walreader.c on a failure. All those messages have no context, making it harder to spot fr= om where an error could come even if these should not happen. All the other callers of XLogReadRecord() do that already. Reviewed-by: Kyotaro Horigu= chi Discussion: https://postgr.es/m/YYnTH6OyOwQcAd= kw@paquier.xyz htt= ps://git.postgresql.org/pg/commitdiff/c9c401a5e13accc4a3a775e3feeabdc5940c9= 178

  • Clean up compilation warnings coming from P= L/Perl with clang-12~. clang-12 has introduced -Wcompound-token-split-by-macro, that is causing a large amoun= t of warnings when building PL/Perl because of its interactions with upstream = Perl. This commit adds one -Wno to CFLAGS at ./configure time if the flag is supported by the compiler to silence all those warnings. Upstream perl h= as fixed this issue, but it is going to take some time before this is spread across the buildfarm, and we have noticed that some animals would be usef= ul with an extra -Werror to help with the detection of incorrect placeholders (see b0cf544), dangomushi being one. Reviewed-by: Tom Lane Discussion: https://postgr.es/m/YYr3qYa/R3Gw+S= bg@paquier.xyz Backpatch-through: 10 h= ttps://git.postgresql.org/pg/commitdiff/9ff47ea414c4e6ace347fc4e59866e38b9b= bceaf

  • Fix buffer overrun in unicode string normal= ization with empty input. PostgreSQL 13 and newer versions are directly impacted by that through th= e SQL function normalize(), which would cause a call of this function to write = one byte past its allocation if using in input an empty string after recompos= ing the string with NFC and NFKC. Older versions (v10~v12) are not directly affected by this problem as the only code path using normalization is SAS= Lprep in SCRAM authentication that forbids the case of an empty string, but let= 's make the code more robust anyway there so as any out-of-core callers of t= his function are covered. The solution chosen to fix this issue is simple, w= ith the addition of a fast-exit path if the decomposed string is found as emp= ty. This would only happen for an empty string as at its lowest level a codep= oint would be decomposed as itself if it has no entry in the decomposition tab= le or if it has a decomposition size of 0. Some tests are added to cover this = issue in v13~. Note that an empty string has always been considered as normali= zed (grammar "IS NF[K]{C,D} NORMALIZED", through the SQL function is_normaliz= ed()) for all the operations allowed (NFC, NFD, NFKC and NFKD) since this featu= re has been introduced as of 2991ac5. This behavior is unchanged but some t= ests are added in v13~ to check after that. I have also checked "make normalization-check" in src/common/unicode/, while on it (works in 13~, a= nd breaks in older stable branches independently of this commit). The relea= se notes should just mention this commit for v13~. Reported-by: Matthijs va= n der Vleuten Discussion: https://postgr.es/m/17277= -0c527a373794e802@postgresql.org Backpatch-through: 10 h= ttps://git.postgresql.org/pg/commitdiff/098c134556664d37b78ae87853a82f4a9d2= 3a2c8

  • Fix memory overrun when querying pg_stat_sl= ru. pg_stat_get_slru() in pgstatfuncs.c would point to one element after the end of the array PgStat_SLRUStats when finishing to scan its entries. This had no direct consequences as no data from the extra memory area was read, but static analyzers would rightfully complain here. So let's be clean. While on i= t, this adds one regression test in the area reserved for system views. Reported-by: Alexander Kozhemyakin, via AddressSanitizer Author: Kyotaro Horiguchi Discussion: https://postgr.es/m/17280= -37da556e86032070@postgresql.org Backpatch-through: 13 h= ttps://git.postgresql.org/pg/commitdiff/a45ed975c58fde7303eeae488b313bf0314= 383f7

Peter Eisentraut pushed:

Jeff Davis pushed:

=C3=81lvaro Herrera pushed:

Peter Geoghegan pushed:

Noah Misch pushed:

Andrew Dunstan pushed:

Daniel Gustafsson pushed:
This email was sent to you from PWN. It was delivered on their behalf by the PostgreSQL project. Any questions about the content of the message shou= ld be sent to PWN.

You were sent this email as a subscriber of the pgsql-announce mai= linglist, for the content tag PWN. To unsubscribe from further emails, or change which emails you want to receive, please click th= e personal unsubscribe link that you can find in the headers of this email, or visit https://lists.postgresql.org/unsubscribe/.
 
--===============8457841827347768312==-- --===============6840132456155053707==--