Skip to main content

Browse the archive

https://github.com/postgres/postgres
02 May 2024, 11:03:54 UTC
sort by:
Revision Author Date Message Commit Date
2b63406 Tom Lane 11 November 2019, 22:11:27 UTC Stamp 9.5.20. 11 November 2019, 22:11:27 UTC
1883134 Tom Lane 11 November 2019, 19:39:55 UTC Doc: fix ancient mistake, or at least obsolete info, in rules example. The example of expansion of multiple views claimed that the resulting subquery nest would not get fully flattened because of an aggregate function. There's no aggregate in the example, though, only a user defined function confusingly named MIN(). In a modern server, the reason for the non-flattening is that MIN() is volatile, but I'm unsure whether that was true back when this text was written. Let's reduce the confusion level by using LEAST() instead (which we didn't have at the time this example was created). And then we can just say that the planner will flatten the sub-queries, so the rewrite system doesn't have to. Noted by Paul Jungwirth. This text is old enough to vote, so back-patch to all supported branches. Discussion: https://postgr.es/m/CA+renyXZFnmp9PcvX1EVR2dR=XG5e6E-AELr8AHCNZ8RYrpnPw@mail.gmail.com 11 November 2019, 19:39:55 UTC
39835ab Peter Eisentraut 11 November 2019, 09:23:30 UTC Translation updates Source-Git-URL: https://git.postgresql.org/git/pgtranslation/messages.git Source-Git-Hash: ccaca304fd66160be942ccf657be787511659ac1 11 November 2019, 09:23:30 UTC
31849d5 Tom Lane 10 November 2019, 23:31:13 UTC Release notes for 12.1, 11.6, 10.11, 9.6.16, 9.5.20, 9.4.25. 10 November 2019, 23:31:13 UTC
30f6998 Tom Lane 09 November 2019, 20:50:16 UTC Remove test case that doesn't work with --disable-integer-timestamps. Commits a7145f6bc et al. added a test to verify integer overflow detection in interval_mul. That only applies with integer timestamps, of course, so it's problematic in pre-v10 branches where we supported float timestamps. The test was only marginally worth the trouble to begin with, so just remove it in those branches. Per buildfarm. Discussion: https://postgr.es/m/6437.1573319193@sss.pgh.pa.us 09 November 2019, 20:50:16 UTC
64b62b7 Peter Eisentraut 08 November 2019, 17:12:51 UTC Fix gratuitous error message variation 08 November 2019, 17:38:07 UTC
b260ce9 Etsuro Fujita 08 November 2019, 08:00:37 UTC postgres_fdw: Fix error message for PREPARE TRANSACTION. Currently, postgres_fdw does not support preparing a remote transaction for two-phase commit even in the case where the remote transaction is read-only, but the old error message appeared to imply that that was not supported only if the remote transaction modified remote tables. Change the message so as to include the case where the remote transaction is read-only. Also fix a comment above the message. Also add a note about the lack of supporting PREPARE TRANSACTION to the postgres_fdw documentation. Reported-by: Gilles Darold Author: Gilles Darold and Etsuro Fujita Reviewed-by: Michael Paquier and Kyotaro Horiguchi Backpatch-through: 9.4 Discussion: https://postgr.es/m/08600ed3-3084-be70-65ba-279ab19618a5%40darold.net 08 November 2019, 08:00:37 UTC
b7ee1d3 Bruce Momjian 07 November 2019, 20:49:59 UTC docs: clarify that only INSERT and UPDATE triggers can mod. NEW The point is that DELETE triggers cannot modify any values. Reported-by: Eugen Konkov Discussion: https://postgr.es/m/919823407.20191029175436@yandex.ru Backpatch-through: 9.4 07 November 2019, 20:49:59 UTC
b705d63 Tom Lane 07 November 2019, 19:21:52 UTC Move declaration of ecpg_gettext() to a saner place. Declaring this in the client-visible header ecpglib.h was a pretty poor decision. It's not meant to be application-callable (and if it was, putting it outside the extern "C" { ... } wrapper means that C++ clients would fail to call it). And the declaration would not even compile for a client, anyway, since it would not have the macro pg_attribute_format_arg(). Fortunately, it seems that no clients have tried to include this header with ENABLE_NLS defined, or we'd have gotten complaints about that. But we have no business putting such a restriction on client code. Move the declaration to ecpglib_extern.h, since in fact nothing outside src/interfaces/ecpg/ecpglib/ needs to call it. The practical effect of this is just that clients can now safely #include ecpglib.h while having ENABLE_NLS defined, but that seems like enough of a reason to back-patch it. Discussion: https://postgr.es/m/20590.1573069709@sss.pgh.pa.us 07 November 2019, 19:21:52 UTC
84780d4 Tom Lane 07 November 2019, 16:22:52 UTC Fix integer-overflow edge case detection in interval_mul and pgbench. This patch adopts the overflow check logic introduced by commit cbdb8b4c0 into two more places. interval_mul() failed to notice if it computed a new microseconds value that was one more than INT64_MAX, and pgbench's double-to-int64 logic had the same sorts of edge-case problems that cbdb8b4c0 fixed in the core code. To make this easier to get right in future, put the guts of the checks into new macros in c.h, and add commentary about how to use the macros correctly. Back-patch to all supported branches, as we did with the previous fix. Yuya Watari Discussion: https://postgr.es/m/CAJ2pMkbkkFw2hb9Qb1Zj8d06EhWAQXFLy73St4qWv6aX=vqnjw@mail.gmail.com 07 November 2019, 16:23:04 UTC
b1bebc2 Fujii Masao 07 November 2019, 07:31:36 UTC Fix assertion failure when running pgbench -s. If there is the WAL page that the continuation WAL record just fits within (i.e., the continuation record ends just at the end of the page) and the LSN in such page is specified with -s option, previously pg_waldump caused an assertion failure. The cause of this assertion failure was that XLogFindNextRecord() that pg_waldump -s calls mistakenly handled such special WAL page. This commit changes XLogFindNextRecord() so that it can handle such WAL page correctly. Back-patch to all supported versions. Author: Andrey Lepikhov Reviewed-by: Fujii Masao, Michael Paquier Discussion: https://postgr.es/m/99303554-5dd5-06e6-f943-b3005ccd6edd@postgrespro.ru 07 November 2019, 07:33:47 UTC
404d25f Michael Paquier 06 November 2019, 07:12:51 UTC Fix timestamp of sent message for write context in logical decoding When sending data for logical decoding using the streaming replication protocol via a WAL sender, the timestamp of the sent write message is allocated at the beginning of the message when preparing for the write, and actually computed when the write message is ready to be sent. The timestamp was getting computed after sending the message. This impacts anything using logical decoding, causing for example logical replication to report mostly NULL for last_msg_send_time in pg_stat_subscription. This commit makes sure that the timestamp is computed before sending the message. This is wrong since 5a991ef, so backpatch down to 9.4. Author: Jeff Janes Discussion: https://postgr.es/m/CAMkU=1z=WMn8jt7iEdC5sYNaPgAgOASb_OW5JYv-vMdYaJSL-w@mail.gmail.com Backpatch-through: 9.4 06 November 2019, 07:12:51 UTC
5c9b0cd Bruce Momjian 06 November 2019, 01:54:04 UTC doc: fix plurality typo on bgwriter doc sentence Reported-by: matthew.alton@gmail.com Discussion: https://postgr.es/m/157204060717.1042.8194076510523669244@wrigleys.postgresql.org Backpatch-through: 9.4 06 November 2019, 01:54:04 UTC
9703720 Tom Lane 05 November 2019, 19:27:37 UTC Avoid logging complaints about abandoned connections when using PAM. For a long time (since commit aed378e8d) we have had a policy to log nothing about a connection if the client disconnects when challenged for a password. This is because libpq-using clients will typically do that, and then come back for a new connection attempt once they've collected a password from their user, so that logging the abandoned connection attempt will just result in log spam. However, this did not work well for PAM authentication: the bottom-level function pam_passwd_conv_proc() was on board with it, but we logged messages at higher levels anyway, for lack of any reporting mechanism. Add a flag and tweak the logic so that the case is silent, as it is for other password-using auth mechanisms. Per complaint from Yoann La Cancellera. It's been like this for awhile, so back-patch to all supported branches. Discussion: https://postgr.es/m/CACP=ajbrFFYUrLyJBLV8=q+eNCapa1xDEyvXhMoYrNphs-xqPw@mail.gmail.com 05 November 2019, 19:27:37 UTC
d386357 Alvaro Herrera 04 November 2019, 18:50:57 UTC Change pg_restore -f- to dump to stdout instead of to ./- Starting with PostgreSQL 12, pg_restore refuses to run when neither -d nor -f are specified (c.f. commit 413ccaa74d9a), and it also makes "-f -" mean the old implicit behavior of dumping to stdout. However, older branches write to a file called ./- when invoked like that, making it impossible to write pg_restore scripts that work across versions. This is a partial backpatch of the aforementioned commit to all older supported branches, providing an upgrade path. Discussion: https://postgr.es/m/20191006190839.GE18030@telsasoft.com 05 November 2019, 12:57:36 UTC
74d32ee Tom Lane 04 November 2019, 21:25:05 UTC Stabilize pg_dump output order for similarly-named triggers and policies. The code only compared two triggers' names and namespaces (the latter being the owning table's schema). This could result in falling back to an OID-based sort of similarly-named triggers on different tables. We prefer to avoid that, so add a comparison of the table names too. (The sort order is thus table namespace, trigger name, table name, which is a bit odd, but it doesn't seem worth contorting the code to work around that.) Likewise for policy objects, in 9.5 and up. Complaint and fix by Benjie Gillam. Back-patch to all supported branches. Discussion: https://postgr.es/m/CAMThMzEEt2mvBbPgCaZ1Ap1N-moGn=Edxmadddjq89WG4NpPtQ@mail.gmail.com 04 November 2019, 21:25:05 UTC
878a9b0 Peter Eisentraut 04 November 2019, 08:54:47 UTC Catch invalid typlens in a couple of places Rearrange the logic in record_image_cmp() and record_image_eq() to error out on unexpected typlens (either not supported there or completely invalid due to corruption). Barring corruption, this is not possible today but it seems more future-proof and robust to fix this. Reported-by: Peter Geoghegan <pg@bowt.ie> 04 November 2019, 09:02:01 UTC
0927d0c Michael Paquier 01 November 2019, 13:39:05 UTC Fix race condition at backend exit when deleting element in syncrep queue When a backend exits, it gets deleted from the syncrep queue if present. The queue was checked without SyncRepLock taken in exclusive mode, so it would have been possible for a backend to remove itself after a WAL sender already did the job. Fix this issue based on a suggestion from Fujii Masao, by first checking the queue without the lock. Then, if the backend is present in the queue, take the lock and perform an additional lookup check before doing the element deletion. Author: Dongming Liu Reviewed-by: Kyotaro Horiguchi, Fujii Masao, Michael Paquier Discussion: https://postgr.es/m/a0806273-8bbb-43b3-bbe1-c45a58f6ae21.lingce.ldm@alibaba-inc.com Backpatch-through: 9.4 01 November 2019, 13:39:05 UTC
39ff656 Andres Freund 30 October 2019, 05:46:40 UTC pg_waldump: Fix --bkp-details to not issue spurious newlines for FPWs. The additional newline seems to have accidentally been introduced in 2c03216d831, in 9.5. The newline is only issued when an FPW is present for the block reference. While there could be an argument that removing the newlines in the back branches could cause a problem for somebody parsing the pg_waldump output, the likelihood of that seems small enough. It seems at least equally likely that the randomness of when newlines are issued causes problems. Author: Andres Freund Discussion: https://postgr.es/m/20191029233341.4gnyau7e5v2lh5sc@alap3.anarazel.de Backpatch: 9.5, like 2c03216d831. 30 October 2019, 05:55:19 UTC
c3882f8 Andres Freund 30 October 2019, 02:18:07 UTC pg_waldump: Fix small memory leak when rmgr->rm_identify returns NULL. This got broken in 604f7956b94, shortly after rm_identify's introduction. Author: Andres Freund Discussion: https://postgr.es/m/20191029233341.4gnyau7e5v2lh5sc@alap3.anarazel.de Backpatch: 9.5, where rm_identify was introduced 30 October 2019, 02:28:34 UTC
7fc50a8 Tom Lane 26 October 2019, 21:37:19 UTC Fix pg_dump's handling of circular dependencies in views. This is a back-patch of the v10 commit d8c05aff5. The motivation for doing this now is that we received a complaint that a view with a circular dependency is dumped with an extra bogus command "ALTER TABLE ONLY myview REPLICA IDENTITY NOTHING", because pg_dump forgets that it's a view not a table, and the relreplident value stored for a view is that. So you'll get an error message during restore even if not using --clean; this would break pg_upgrade for example. While that could be handled with a one-line patch, it seems better to back-patch d8c05aff5, since that produces cleaner more future-proof output and fixes an additional bug. Per gripe from Alex Williams. Back-patch to 9.4-9.6 (even if 9.3 were still in support, it hasn't got REPLICA IDENTITY so no bug). Discussion: https://postgr.es/m/NFqxoEi7-8Rw9OW0f-GwHcjvS2I4YQXov4g9OoWv3i7lVOZdLWkAWl9jQQqwEaUq6WV0vdobromhW82e8y5I0_59yZTXcZnXsrmFuldlmZc=@protonmail.com Original commit message follows: pg_dump's traditional solution for breaking a circular dependency involving a view was to create the view with CREATE TABLE and then later issue CREATE RULE "_RETURN" ... to convert the table to a view, relying on the backend's very very ancient code that supports making views that way. We've wanted to get rid of that kluge for a long time, but the thing that finally motivates doing something about it is the recognition that this method fails with the --clean option, because it leads to issuing DROP RULE "_RETURN" followed by DROP TABLE --- and the backend won't let you drop a view's _RETURN rule. Instead, let's break circular dependencies by initially creating the view using CREATE VIEW AS SELECT NULL::columntype AS columnname, ... (so that it has the right column names and types to support external references, but no dependencies beyond the column data types), and then later dumping the ON SELECT rule using the spelling CREATE OR REPLACE VIEW. This method wasn't available when this code was originally written, but it's been possible since PG 7.3, so it seems fine to start relying on it now. To solve the --clean problem, make the dropStmt for an ON SELECT rule be CREATE OR REPLACE VIEW with the same dummy target list as above. In this way, during the DROP phase, we first reduce the view to have no extra dependencies, and then we can drop it entirely when we've gotten rid of whatever had a circular dependency on it. (Note: this should work adequately well with the --if-exists option, since the CREATE OR REPLACE VIEW will go through whether the view exists or not. It could fail if the view exists with a conflicting column set, but we don't really support --clean against a non-matching database anyway.) This allows cleaning up some other kluges inside pg_dump, notably that we don't need a notion of reloptions attached to a rule anymore. Although this is a bug fix, commit to HEAD only for now. The problem's existed for a long time and we've had relatively few complaints, so it doesn't really seem worth taking risks to fix it in the back branches. We might revisit that choice if no problems emerge. Discussion: <19092.1479325184@sss.pgh.pa.us> 26 October 2019, 21:37:19 UTC
4e3be56 Bruce Momjian 24 October 2019, 00:29:02 UTC docs: fix wording of REFRESH CONCURRENTLY manual page Reported-by: Asim / apraveen@pivotal.io Discussion: https://postgr.es/m/157076828181.26165.15231292023740913543@wrigleys.postgresql.org Backpatch-through: 9.4 24 October 2019, 00:29:02 UTC
ebf7b2e Michael Paquier 23 October 2019, 01:26:23 UTC Clean up properly error_context_stack in autovacuum worker on exception Any callback set would have no meaning in the context of an exception. As an autovacuum worker exits quickly in this context, this could be only an issue within EmitErrorReport(), where the elog hook is for example called. That's unlikely to going to be a problem, but let's be clean and consistent with other code paths handling exceptions. This is present since 2909419, which introduced autovacuum. Author: Ashwin Agrawal Reviewed-by: Tom Lane, Michael Paquier Discussion: https://postgr.es/m/CALfoeisM+_+dgmAdAOHAu0k-ZpEHHqSSG=GRf3pKJGm8OqWX0w@mail.gmail.com Backpatch-through: 9.4 23 October 2019, 01:26:23 UTC
e326740 Tom Lane 21 October 2019, 18:18:01 UTC Deal with yet another issue related to "Norwegian (Bokmål)" locale. It emerges that recent versions of Windows (at least 2016 Standard) spell this locale name as "Norwegian Bokmål_Norway.1252", defeating our mapping code that translates "Norwegian (Bokmål)_Norway" to something that's all-ASCII (cf commits db29620d4 and aa1d2fc5e). Add another mapping entry to handle this spelling. Per bug #16068 from Robert Ford. Like the previous patches, back-patch to all supported branches. Discussion: https://postgr.es/m/16068-4cb6eeaa7eb46d93@postgresql.org 21 October 2019, 18:18:55 UTC
8835e0b Tom Lane 21 October 2019, 17:52:26 UTC Use CFLAGS_SL while probing linkability of libperl. On recent Red Hat platforms (at least RHEL 8 and Fedora 30, maybe older), configure's probe for libperl failed if the user forces CFLAGS to be -O0. This is because some code in perl's inline.h fails to be optimized away at -O0, and said code doesn't work if compiled without -fPIC. To fix, add CFLAGS_SL to the compile flags used during the libperl probe. This is a better simulation of the way that plperl is built, anyway, so it might forestall other issues in future. Per gripe from Kyotaro Horiguchi. Back-patch to all supported branches, since people might want to build older branches on these platforms. Discussion: https://postgr.es/m/20191010.144533.263180400.horikyota.ntt@gmail.com 21 October 2019, 17:52:26 UTC
11330c3 Tom Lane 21 October 2019, 16:32:36 UTC Select CFLAGS_SL at configure time, not in platform-specific Makefiles. Move the platform-dependent logic that sets CFLAGS_SL from src/makefiles/Makefile.foo to src/template/foo, so that the value is determined at configure time and thus is available while running configure's tests. On a couple of platforms this might save a few microseconds of build time by eliminating a test that make otherwise has to do over and over. Otherwise it's pretty much a wash for build purposes; in particular, this makes no difference to anyone who might be overriding CFLAGS_SL via a make option. This patch in itself does nothing with the value and thus should not change any behavior, though you'll probably have to re-run configure to get a correctly updated Makefile.global. We'll use the new configure variable in a follow-on patch. Per gripe from Kyotaro Horiguchi. Back-patch to all supported branches, because the follow-on patch is a portability bug fix. Discussion: https://postgr.es/m/20191010.144533.263180400.horikyota.ntt@gmail.com 21 October 2019, 16:32:36 UTC
62e8819 Noah Misch 19 October 2019, 03:20:28 UTC For PowerPC instruction "addi", use constraint "b". Without "b", a variant of the tas() code miscompiles on macOS 10.4. This may also fix a compilation failure involving macOS 10.1. Today's compilers have been allocating acceptable registers with or without this change, but this future-proofs the code by precisely conveying the acceptable registers. Back-patch to 9.4 (all supported versions). Reviewed by Tom Lane. Discussion: https://postgr.es/m/20191009063900.GA4066266@rfd.leadboat.com 19 October 2019, 03:20:32 UTC
1b2ba88 Fujii Masao 18 October 2019, 13:32:18 UTC Fix failure of archive recovery with recovery_min_apply_delay enabled. recovery_min_apply_delay parameter is intended for use with streaming replication deployments. However, the document clearly explains that the parameter will be honored in all cases if it's specified. So it should take effect even if in archive recovery. But, previously, archive recovery with recovery_min_apply_delay enabled always failed, and caused assertion failure if --enable-caasert is enabled. The cause of this problem is that; the ownership of recoveryWakeupLatch that recovery_min_apply_delay uses was taken only when standby mode is requested. So unowned latch could be used in archive recovery, and which caused the failure. This commit changes recovery code so that the ownership of recoveryWakeupLatch is taken even in archive recovery. Which prevents archive recovery with recovery_min_apply_delay from failing. Back-patch to v9.4 where recovery_min_apply_delay was added. Author: Fujii Masao Reviewed-by: Michael Paquier Discussion: https://postgr.es/m/CAHGQGwEyD6HdZLfdWc+95g=VQFPR4zQL4n+yHxQgGEGjaSVheQ@mail.gmail.com 18 October 2019, 13:35:41 UTC
b2ab06e Alvaro Herrera 17 October 2019, 13:06:05 UTC Fix minor bug in logical-replication walsender shutdown Logical walsender should exit when it catches up with sending WAL during shutdown; but there was a rare corner case when it failed to because of a race condition that puts it back to wait for more WAL instead -- but since there wasn't any, it'd not shut down immediately. It would only continue the shutdown when wal_sender_timeout terminates the sleep, which causes annoying waits during shutdown procedure. Restructure the code so that we no longer forget to set WalSndCaughtUp in that case. This was an oversight in commit c6c333436. Backpatch all the way down to 9.4. Author: Craig Ringer, Álvaro Herrera Discussion: https://postgr.es/m/CAMsr+YEuz4XwZX_QmnX_-2530XhyAmnK=zCmicEnq1vLr0aZ-g@mail.gmail.com 17 October 2019, 13:06:05 UTC
cdbb392 Thomas Munro 17 October 2019, 00:24:50 UTC When restoring GUCs in parallel workers, show an error context. Otherwise it can be hard to see where an error is coming from, when the parallel worker sets all the GUCs that it received from the leader. Bug #15726. Back-patch to 9.5, where RestoreGUCState() appeared. Reported-by: Tiago Anastacio Reviewed-by: Daniel Gustafsson, Tom Lane Discussion: https://postgr.es/m/15726-6d67e4fa14f027b3%40postgresql.org 17 October 2019, 00:50:59 UTC
c1443ee Thomas Munro 16 October 2019, 20:59:21 UTC Fix bug that could try to freeze running multixacts. Commits 801c2dc7 and 801c2dc7 made it possible for vacuum to try to freeze a multixact that is still running. That was prevented by a check, but raised an error. Repair. Back-patch all the way. Author: Nathan Bossart, Jeremy Schneider Reported-by: Jeremy Schneider Reviewed-by: Jim Nasby, Thomas Munro Discussion: https://postgr.es/m/DAFB8AFF-2F05-4E33-AD7F-FF8B0F760C17%40amazon.com 16 October 2019, 21:28:28 UTC
984aa0e Tomas Vondra 16 October 2019, 14:08:40 UTC Add missing include to pg_upgrade/version.c Commit 8d48e6a724 uses RELKIND_ constants when building the query, but did not include the header defining them. On 10+ this header is already included, but on 9.6 and earlier it was missing. It compiles just fine, but then fails during execution ERROR: column "relkind_relation" does not exist Fix by adding the necessary header file, and backpatch to 9.4-. Backpatch-to: 9.4- Discussion: https://postgr.es/m/16045-673e8fa6b5ace196%40postgresql.org 16 October 2019, 14:23:09 UTC
f57b01d Tomas Vondra 16 October 2019, 11:23:14 UTC Improve the check for pg_catalog.line data type in pg_upgrade The pg_upgrade check for pg_catalog.line data type when upgrading from 9.3 had a couple of issues with domains and composite types. Firstly, it triggered false positives for composite types unused in objects with storage. This was enough to trigger an unnecessary pg_upgrade failure: CREATE TYPE line_composite AS (l pg_catalog.line) On the other hand, this only happened with composite types directly on the pg_catalog.line data type, but not with a domain. So this was not detected CREATE DOMAIN line_domain AS pg_catalog.line; CREATE TYPE line_composite_2 AS (l line_domain); unlike the first example. These false positives and inconsistencies are unfortunate, but what's worse we've failed to detected objects using the pg_catalog.line data type through a domain. So we missed cases like this CREATE TABLE t (l line_composite_2); The consequence is clusters broken after a pg_upgrade. This fixes these false positives and false negatives by using the same recursive CTE introduced by eaf900e842 for sql_identifier. 9.3 did not support domains on composite types, but we can still have multi-level composite types. Backpatch all the way to 9.4, where the format for pg_catalog.line data type changed. Author: Tomas Vondra Backpatch-to: 9.4- Discussion: https://postgr.es/m/16045-673e8fa6b5ace196%40postgresql.org 16 October 2019, 11:27:51 UTC
6ddc406 Michael Paquier 16 October 2019, 04:10:57 UTC Doc: Fix various inconsistencies This fixes multiple areas of the documentation: - COPY for its past compatibility section. - SET ROLE mentioning INHERITS instead of INHERIT - PREPARE referring to stmt_name, that is not present. - Extension documentation about format name with upgrade scripts. Backpatch down to 9.4 for the relevant parts. Author: Alexander Lakhin Discussion: https://postgr.es/m/bf95233a-9943-b341-e2ff-a860c28af481@gmail.com Backpatch-through: 9.4 16 October 2019, 04:10:57 UTC
e40eb31 Noah Misch 12 October 2019, 07:21:47 UTC AIX: Stop adding option -qsrcmsg. With xlc v16.1.0, it causes internal compiler errors. With xlc versions not exhibiting that bug, removing -qsrcmsg merely changes the compiler error reporting format. Back-patch to 9.4 (all supported versions). Discussion: https://postgr.es/m/20191003064105.GA3955242@rfd.leadboat.com 12 October 2019, 07:21:51 UTC
c50f952 Michael Paquier 09 October 2019, 04:31:33 UTC Flush logical mapping files with fd opened for read/write at checkpoint The file descriptor was opened with read-only to fsync a regular file, which would cause EBADFD errors on some platforms. This is similar to the recent fix done by a586cc4b (which was broken by me with 82a5649), except that I noticed this issue while monitoring the backend code for similar mistakes. Backpatch to 9.4, as this has been introduced since logical decoding exists as of b89e151. Author: Michael Paquier Reviewed-by: Andres Freund Discussion: https://postgr.es/m/20191006045548.GA14532@paquier.xyz Backpatch-through: 9.4 09 October 2019, 04:31:33 UTC
4fe04a6 Bruce Momjian 07 October 2019, 22:06:07 UTC docs: Improve A?synchronous Multimaster Replication descr. The docs for sync and async multimaster replication were unclear about when to use it, and when it has benefits; this change clarifies that. Reported-by: juha-pekka.eloranta@reaktor.fi Discussion: https://postgr.es/m/156856543824.1274.12180817186798859836@wrigleys.postgresql.org Backpatch-through: 9.4 07 October 2019, 22:06:07 UTC
315c7a8 Bruce Momjian 07 October 2019, 21:26:46 UTC docs: clarify that today/tomorrow/yesterday is at 00:00 This should help people clearly know that these days start at midnight. Reported-by: David Harper Discussion: https://postgr.es/m/156258047907.1181.11324468080514061996@wrigleys.postgresql.org Backpatch-through: 9.4 07 October 2019, 21:26:46 UTC
cf3187e Bruce Momjian 07 October 2019, 18:33:31 UTC doc: move mention of log_min_error_statement in a better spot Previously it was mentioned in the lock_timeout docs in a confusing location. Reported-by: ivaylo.zlatanov@gmail.com Discussion: https://postgr.es/m/157019615723.25307.15449102262106437404@wrigleys.postgresql.org Backpatch-through: 9.4 07 October 2019, 18:33:31 UTC
8c2910c Tom Lane 07 October 2019, 16:39:10 UTC Check for too many postmaster children before spawning a bgworker. The postmaster's code path for spawning a bgworker neglected to check whether we already have the max number of live child processes. That's a bit hard to hit, since it would necessarily be a transient condition; but if we do, AssignPostmasterChildSlot() fails causing a postmaster crash, as seen in a report from Bhargav Kamineni. To fix, invoke canAcceptConnections() in the bgworker code path, as we do in the other code paths that spawn children. Since we don't want the same pmState tests in this case, add a child-process-type parameter to canAcceptConnections() so that it can know what to do. Back-patch to 9.5. In principle the same hazard exists in 9.4, but the code is enough different that this patch wouldn't quite fix it there. Given the tiny usage of bgworkers in that branch it doesn't seem worth creating a variant patch for it. Discussion: https://postgr.es/m/18733.1570382257@sss.pgh.pa.us 07 October 2019, 16:39:10 UTC
57f0060 Noah Misch 05 October 2019, 17:05:05 UTC Report test_atomic_ops() failures consistently, via macros. This prints the unexpected value in more failure cases, and it removes forty-eight hand-maintained error messages. Back-patch to 9.5, which introduced these tests. Reviewed (in an earlier version) by Andres Freund. Discussion: https://postgr.es/m/20190915160021.GA24376@alvherre.pgsql 05 October 2019, 17:06:40 UTC
6ca51b1 Andrew Dunstan 04 October 2019, 19:34:40 UTC Handle spaces in OpenSSL install location for MSVC First, make sure that the .exe name is quoted when trying to get the version number. Also, don't quote the lib name for using in the project files if it's already been quoted. This second change applies to all libraries, not just OpenSSL. This has clearly been broken forever, so backpatch to all live branches. 04 October 2019, 19:38:48 UTC
8b77f78 Tom Lane 04 October 2019, 14:34:21 UTC Fix bitshiftright()'s zero-padding some more. Commit 5ac0d9360 failed to entirely fix bitshiftright's habit of leaving one-bits in the pad space that should be all zeroes, because in a moment of sheer brain fade I'd concluded that only the code path used for not-a-multiple-of-8 shift distances needed to be fixed. Of course, a multiple-of-8 shift distance can also cause the problem, so we need to forcibly zero the extra bits in both cases. Per bug #16037 from Alexander Lakhin. As before, back-patch to all supported branches. Discussion: https://postgr.es/m/16037-1d1ebca564db54f4@postgresql.org 04 October 2019, 14:34:21 UTC
54d641d Tom Lane 03 October 2019, 21:34:26 UTC Avoid unnecessary out-of-memory errors during encoding conversion. Encoding conversion uses the very simplistic rule that the output can't be more than 4X longer than the input, and palloc's a buffer of that size. This results in failure to convert any string longer than 1/4 GB, which is becoming an annoying limitation. As a band-aid to improve matters, allow the allocated output buffer size to exceed 1GB. We still insist that the final result fit into MaxAllocSize (1GB), though. Perhaps it'd be safe to relax that restriction, but it'd require close analysis of all callers, which is daunting (not least because external modules might call these functions). For the moment, this should allow a 2X to 4X improvement in the longest string we can convert, which is a useful gain in return for quite a simple patch. Also, once we have successfully converted a long string, repalloc the output down to the actual string length, returning the excess to the malloc pool. This seems worth doing since we can usually expect to give back several MB if we take this path at all. This still leaves much to be desired, most notably that the assumption that MAX_CONVERSION_GROWTH == 4 is very fragile, and yet we have no guard code verifying that the output buffer isn't overrun. Fixing that would require significant changes in the encoding conversion APIs, so it'll have to wait for some other day. The present patch seems safely back-patchable, so patch all supported branches. Alvaro Herrera and Tom Lane Discussion: https://postgr.es/m/20190816181418.GA898@alvherre.pgsql Discussion: https://postgr.es/m/3614.1569359690@sss.pgh.pa.us 03 October 2019, 21:34:26 UTC
1534531 Tom Lane 03 October 2019, 17:56:26 UTC Allow repalloc() to give back space when a large chunk is downsized. Up to now, if you resized a large (>8K) palloc chunk down to a smaller size, aset.c made no attempt to return any space to the malloc pool. That's unpleasant if a really large allocation is resized to a significantly smaller size. I think no such cases existed when this code was designed, and I'm not sure whether they're common even yet, but an upcoming fix to encoding conversion will certainly create such cases. Therefore, fix AllocSetRealloc so that it gives realloc() a chance to do something with the block. This doesn't noticeably increase complexity, we mostly just have to change the order in which the cases are considered. Back-patch to all supported branches. Discussion: https://postgr.es/m/20190816181418.GA898@alvherre.pgsql Discussion: https://postgr.es/m/3614.1569359690@sss.pgh.pa.us 03 October 2019, 17:56:26 UTC
d2427f1 Andrew Gierth 03 October 2019, 09:54:52 UTC Selectively include window frames in expression walks/mutates. query_tree_walker and query_tree_mutator were skipping the windowClause of the query, without regard for the fact that the startOffset and endOffset in a WindowClause node are expression trees that need to be processed. This was an oversight in commit ec4be2ee6 from 2010 which added the expression fields; the main symptom is that function parameters in window frame clauses don't work in inlined functions. Fix (as conservatively as possible since this needs to not break existing out-of-tree callers) and add tests. Backpatch all the way, since this has been broken since 9.0. Per report from Alastair McKinley; fix by me with kibitzing and review from Tom Lane. Discussion: https://postgr.es/m/DB6PR0202MB2904E7FDDA9D81504D1E8C68E3800@DB6PR0202MB2904.eurprd02.prod.outlook.com 03 October 2019, 10:18:15 UTC
ae205df Michael Paquier 02 October 2019, 06:54:16 UTC Remove temporary WAL and history files at the end of archive recovery cbc55da has reworked the order of some actions at the end of archive recovery. Unfortunately this overlooked the fact that the startup process needs to remove RECOVERYXLOG (for temporary WAL segment newly recovered from archives) and RECOVERYHISTORY (for temporary history file) at this step, leaving the files around even after recovery ended. Backpatch to 9.5, like the previous commit. Author: Sawada Masahiko Reviewed-by: Fujii Masao, Michael Paquier Discussion: https://postgr.es/m/CAD21AoBO_eDQub6zojFnWtnmutRBWvYf7=cW4Hsqj+U_R26w3Q@mail.gmail.com Backpatch-through: 9.5 02 October 2019, 06:54:16 UTC
0997cee Tom Lane 27 September 2019, 15:01:37 UTC Doc: clean up markup for jsonb_set and related functions. The markup for optional parameters was neither correct nor consistent. In passing, fix a spelling mistake. Per report from Alex Macy. Some of these mistakes are old, so back-patch as appropriate. Discussion: https://postgr.es/m/156953522258.1204.12736099368284950578@wrigleys.postgresql.org 27 September 2019, 15:01:37 UTC
8364ef9 Amit Kapila 18 September 2019, 03:44:26 UTC Fix oversight in commit 4429f6a9e3e12bb4af6e3677fbc78cd80f160252. The test name and the following test cases suggest the index created should be hash index, but it forgot to add 'using hash' in the test case. This in itself won't improve code coverage as there were some other tests which were covering the corresponding code. However, it is better if the added tests serve their actual purpose. Reported-by: Paul A Jungwirth Author: Paul A Jungwirth Reviewed-by: Mahendra Singh Backpatch-through: 9.4 Discussion: https://postgr.es/m/CA+renyV=Us-5XfMC25bNp-uWSj39XgHHmGE9Rh2cQKMegSj52g@mail.gmail.com 27 September 2019, 03:14:28 UTC
65cddf7 Tom Lane 23 September 2019, 16:37:04 UTC Doc: clarify handling of duplicate elements in array containment tests. The array <@ and @> operators do not worry about duplicates: if every member of array X matches some element of array Y, then X is contained in Y, even if several members of X get matched to the same Y member. This was not explicitly stated in the docs though, so improve matters. Discussion: https://postgr.es/m/156614120484.1310.310161642239149585@wrigleys.postgresql.org 23 September 2019, 16:37:04 UTC
35eb132 Tom Lane 22 September 2019, 21:46:00 UTC Fix failure to zero-pad the result of bitshiftright(). If the bitstring length is not a multiple of 8, we'd shift the rightmost bits into the pad space, which must be zeroes --- bit_cmp, for one, depends on that. This'd lead to the result failing to compare equal to what it should compare equal to, as reported in bug #16013 from Daryl Waycott. This is, if memory serves, not the first such bug in the bitstring functions. In hopes of making it the last one, do a bit more work than minimally necessary to fix the bug: * Add assertion checks to bit_out() and varbit_out() to complain if they are given incorrectly-padded input. This will improve the odds that manual testing of any new patch finds problems. * Encapsulate the padding-related logic in macros to make it easier to use. Also, remove unnecessary padding logic from bit_or() and bitxor(). Somebody had already noted that we need not re-pad the result of bit_and() since the inputs are required to be the same length, but failed to extrapolate that to the other two. Also, move a comment block that once was near the head of varbit.c (but people kept putting other stuff in front of it), to put it in the header block. Note for the release notes: if anyone has inconsistent data as a result of saving the output of bitshiftright() in a table, it's possible to fix it with something like UPDATE mytab SET bitcol = ~(~bitcol) WHERE bitcol != ~(~bitcol); This has been broken since day one, so back-patch to all supported branches. Discussion: https://postgr.es/m/16013-c2765b6996aacae9@postgresql.org 22 September 2019, 21:46:00 UTC
128abde Tom Lane 20 September 2019, 23:53:33 UTC Update time zone data files to tzdata release 2019c. DST law changes in Fiji and Norfolk Island. Historical corrections for Alberta, Austria, Belgium, British Columbia, Cambodia, Hong Kong, Indiana (Perry County), Kaliningrad, Kentucky, Michigan, Norfolk Island, South Korea, and Turkey. 20 September 2019, 23:54:29 UTC
6133c59 Amit Kapila 20 September 2019, 02:35:54 UTC Fix typo in commit 82fa3ff8672. Reported-By: Kuntal Ghosh (off-list) Backpatch-through: 9.4, like 82fa3ff8672 20 September 2019, 02:52:13 UTC
3889397 Alexander Korotkov 19 September 2019, 20:36:01 UTC Fix oversight in backpatch of 6cae9d2c10 During backpatch of 6cae9d2c10 Float8GetDatum() was accidentally removed. This commit turns it back. Reported-by: Erik Rijkers Discussion: https://postgr.es/m/6d51305e1159241cabee132f7efc7eff%40xs4all.nl Author: Tom Lane Backpatch-through: from 11 to 9.5 19 September 2019, 20:39:35 UTC
ad458d0 Alexander Korotkov 19 September 2019, 18:30:19 UTC Improve handling of NULLs in KNN-GiST and KNN-SP-GiST This commit improves subject in two ways: * It removes ugliness of 02f90879e7, which stores distance values and null flags in two separate arrays after GISTSearchItem struct. Instead we pack both distance value and null flag in IndexOrderByDistance struct. Alignment overhead should be negligible, because we typically deal with at most few "col op const" expressions in ORDER BY clause. * It fixes handling of "col op NULL" expression in KNN-SP-GiST. Now, these expression are not passed to support functions, which can't deal with them. Instead, NULL result is implicitly assumed. It future we may decide to teach support functions to deal with NULL arguments, but current solution is bugfix suitable for backpatch. Reported-by: Nikita Glukhov Discussion: https://postgr.es/m/826f57ee-afc7-8977-c44c-6111d18b02ec%40postgrespro.ru Author: Nikita Glukhov Reviewed-by: Alexander Korotkov Backpatch-through: 9.4 19 September 2019, 19:09:51 UTC
14936be Michael Paquier 19 September 2019, 04:19:19 UTC Doc: Fix incorrect mention to connection_object in CONNECT command of ECPG This fixes an inconsistency with this parameter name not listed in the command synopsis, and connection_name is the parameter name more commonly used in the docs for ECPG commands. Reported-by: Yusuke Egashita Discussion: https://postgr.es/m/156870956796.1259.11456186889345212399@wrigleys.postgresql.org Backpatch-through: 9.4 19 September 2019, 04:19:19 UTC
c106461 Amit Kapila 19 September 2019, 03:43:31 UTC Doc: document autovacuum interruption. It's important users be able to know (without looking at the source code) that running DDL or DDL-like commands can interrupt autovacuum which can lead to a lot of dead tuples and hence slower database operations. Reported-by: James Coleman Author: James Coleman Reviewed-by: Amit Kapila Backpatch-through: 9.4 Discussion: https://postgr.es/m/CAAaqYe-XYyNwML1=f=gnd0qWg46PnvD=BDrCZ5-L94B887XVxQ@mail.gmail.com 19 September 2019, 03:43:31 UTC
50261e1 Alvaro Herrera 18 September 2019, 14:24:12 UTC pg_upgrade/test.sh: Quote sed(1) argument Lack of quotes results in failure to run the test under older Solaris. Author: Marina Polyakova, Victor Wagner Discussion: https://postgr.es/m/feba89f89e8925b3535cb7d72b9e05e1@postgrespro.ru 18 September 2019, 14:25:32 UTC
75941f2 Noah Misch 14 September 2019, 02:34:06 UTC Replace xlc __fetch_and_add() with inline asm. PostgreSQL has been unusable when built with xlc 13 and newer, which are incompatible with our use of __fetch_and_add(). Back-patch to 9.5, which introduced pg_atomic_fetch_add_u32(). Reviewed by Tom Lane. Discussion: https://postgr.es/m/20190831071157.GA3251746@rfd.leadboat.com 14 September 2019, 02:34:19 UTC
4737d3a Noah Misch 14 September 2019, 02:33:30 UTC Test pg_atomic_fetch_add_ with variable addend and 16-bit edge cases. Back-patch to 9.5, which introduced these functions. Reviewed by Tom Lane. Discussion: https://postgr.es/m/20190831071157.GA3251746@rfd.leadboat.com 14 September 2019, 02:33:47 UTC
7110f5c Alvaro Herrera 13 September 2019, 19:36:28 UTC logical decoding: process ASSIGNMENT during snapshot build Most WAL records are ignored in early SnapBuild snapshot build phases. But it's critical to process some of them, so that later messages have the correct transaction state after the snapshot is completely built; in particular, XLOG_XACT_ASSIGNMENT messages are critical in order for sub-transactions to be correctly assigned to their parent transactions, or at least one assert misbehaves, as reported by Ildar Musin. Diagnosed-by: Masahiko Sawada Author: Masahiko Sawada Discussion: https://postgr.es/m/CAONYFtOv+Er1p3WAuwUsy1zsCFrSYvpHLhapC_fMD-zNaRWxYg@mail.gmail.com 13 September 2019, 19:36:28 UTC
83c2c97 Alvaro Herrera 13 September 2019, 19:26:55 UTC Fix under-parenthesized macro definitions Lack of parens in the definitions could cause a statement using these macros to have unexpected semantics. In current code no bug is apparent, but best to fix the definitions to avoid problems down the line. Reported-by: Tom Lane Discussion: https://postgr.es/m/19795.1568400476@sss.pgh.pa.us 13 September 2019, 19:26:55 UTC
9064cc1 Peter Geoghegan 12 September 2019, 22:44:59 UTC Fix nbtree page split rmgr desc routine. Include newitemoff in rmgr desc output for nbtree page split records. In passing, correct an obsolete comment that claimed that newitemoff is only logged for _L variant nbtree page split WAL records. Both issues were oversights in commit 2c03216d831, which revamped the WAL format. Author: Peter Geoghegan Backpatch: 9.5-, where the WAL format was revamped. 12 September 2019, 22:44:59 UTC
aee5736 Tom Lane 12 September 2019, 22:29:18 UTC Fix usage of whole-row variables in WCO and RLS policy expressions. Since WITH CHECK OPTION was introduced, ExecInitModifyTable has initialized WCO expressions with the wrong plan node as parent -- that is, it passed its input subplan not the ModifyTable node itself. Up to now we thought this was harmless, but bug #16006 from Vinay Banakar shows it's not: if the input node is a SubqueryScan then ExecInitWholeRowVar can get confused into doing the wrong thing. (The fact that ExecInitWholeRowVar contains such logic is certainly a horrid kluge that doesn't deserve to live, but figuring out another way to do that is a task for some other day.) Andres had already noticed the wrong-parent mistake and fixed it in commit 148e632c0, but not being aware of any user-visible consequences, he quite reasonably didn't back-patch. This patch is simply a back-patch of 148e632c0, plus addition of a test case based on bug #16006. I also added the test case to v12/HEAD, even though the bug is already fixed there. Back-patch to all supported branches. 9.4 lacks RLS policies so the new test case doesn't work there, but I'm pretty sure a test could be devised based on using a whole-row Var in a plain WITH CHECK OPTION condition. (I lack the cycles to do so myself, though.) Andres Freund and Tom Lane Discussion: https://postgr.es/m/16006-99290d2e4642cbd5@postgresql.org Discussion: https://postgr.es/m/20181205225213.hiwa3kgoxeybqcqv@alap3.anarazel.de 12 September 2019, 22:29:18 UTC
1ae5783 Amit Kapila 11 September 2019, 04:55:49 UTC Doc: Update PL/pgSQL sample function in plpgsql.sgml. The example used to explain 'Looping Through Query Results' uses pseudo-materialized views. Replace it with a more up-to-date example which does the same thing with actual materialized views, which have been available since PostgreSQL 9.3. In the passing, change '%' as format specifier instead of '%s' as is used in other examples in plpgsql.sgml. Reported-by: Ian Barwick Author: Ian Barwick Reviewed-by: Amit Kapila Backpatch-through: 9.4 Discussion: https://postgr.es/m/9a70d393-7904-4918-c97c-649f6d114b6a@2ndquadrant.com 12 September 2019, 08:45:08 UTC
bfd6db8 Michael Paquier 11 September 2019, 02:07:44 UTC Expand properly list of TAP tests used for prove in vcregress.pl Depending on the system used, t/*.pl may not be expanded into a list of tests which can be consumed by prove when attempting to run TAP tests on a given path. Fix that by using glob() directly in the script, to make sure that a complete list of tests is provided. This has not proved to be an issue with MSVC as the list was properly expanded, but it is on Linux with perl's system(). This is extracted from a larger patch. Author: Tom Lane Discussion: https://postgr.es/m/6628.1567958876@sss.pgh.pa.us Backpatch-through: 9.4 11 September 2019, 02:07:44 UTC
decff80 Andrew Dunstan 09 September 2019, 12:56:33 UTC Prevent msys2 conversion of "cmd /c" switch to a file path Modern versions of msys2 have changed the treatment of "cmd /c" so that the runtime will try to convert the switch to a native file path. This patch adds a setting to inhibit that behaviour. Discussion: https://postgr.es/m/3227042f-cfcc-745a-57dd-fb8c471f8ddf@2ndQuadrant.com Backpatch to all live branches. 09 September 2019, 13:03:32 UTC
87ee158 Tom Lane 08 September 2019, 21:00:29 UTC Fix RelationIdGetRelation calls that weren't bothering with error checks. Some of these are quite old, but that doesn't make them not bugs. We'd rather report a failure via elog than SIGSEGV. While at it, uniformly spell the error check as !RelationIsValid(rel) rather than a bare rel == NULL test. The machine code is the same but it seems better to be consistent. Coverity complained about this today, not sure why, because the mistake is in fact old. 08 September 2019, 21:00:57 UTC
3c155ba Alexander Korotkov 08 September 2019, 18:13:40 UTC Fix handling of NULL distances in KNN-GiST In order to implement NULL LAST semantic GiST previously assumed distance to the NULL value to be Inf. However, our distance functions can return Inf and NaN for non-null values. In such cases, NULL LAST semantic appears to be broken. This commit fixes that by introducing separate array of null flags for distances. Backpatch to all supported versions. Discussion: https://postgr.es/m/CAPpHfdsNvNdA0DBS%2BwMpFrgwT6C3-q50sFVGLSiuWnV3FqOJuQ%40mail.gmail.com Author: Alexander Korotkov Backpatch-through: 9.4 08 September 2019, 18:49:16 UTC
986319d Alexander Korotkov 08 September 2019, 18:07:30 UTC Fix handling Inf and Nan values in GiST pairing heap comparator Previously plain float comparison was used in GiST pairing heap. Such comparison doesn't provide proper ordering for value sets containing Inf and Nan values. This commit fixes that by usage of float8_cmp_internal(). Note, there is remaining problem with NULL distances, which are represented as Inf in pairing heap. It would be fixes in subsequent commit. Backpatch to all supported versions. Reported-by: Andrey Borodin Discussion: https://postgr.es/m/CAPpHfdsNvNdA0DBS%2BwMpFrgwT6C3-q50sFVGLSiuWnV3FqOJuQ%40mail.gmail.com Author: Alexander Korotkov Reviewed-by: Heikki Linnakangas Backpatch-through: 9.4 08 September 2019, 18:49:15 UTC
f1a9abe Tom Lane 08 September 2019, 17:45:13 UTC configure: Update python search order Some systems don't ship with "python" by default anymore, only "python3" or "python2" or some combination, so include those in the configure search. Back-patch of commit 7291733ac. At the time that was only pushed back as far as v10, because of concerns about interactions with commit b21c569ce. Closer analysis shows that if we just s/AC_PATH_PROG/AC_PATH_PROGS/, there is no effect on the older branches' behavior when PYTHON is explicitly specified, so it should be okay to back-patch: this will not break any configuration that worked before. And the need to support platforms with only a "python3" or "python2" executable is getting ever more urgent. Original patch by Peter Eisentraut, back-patch analysis by me Discussion: https://www.postgresql.org/message-id/flat/1457.1543184081%40sss.pgh.pa.us#c9cc1199338fd6a257589c6dcea6cf8d 08 September 2019, 17:45:13 UTC
3f68d13 Peter Eisentraut 06 September 2019, 20:19:53 UTC doc: Fix awkward markup 06 September 2019, 20:21:37 UTC
f697c63 Robert Haas 06 September 2019, 12:22:32 UTC When performing a base backup, check for read errors. The old code didn't differentiate between a read error and a concurrent truncation. fread reports both of these by returning 0; you have to use feof() or ferror() to distinguish between them, which this code did not do. It might be a better idea to use read() rather than fread() here, so that we can display a less-generic error message, but I'm not sure that would qualify as a back-patchable bug fix, so just do this much for now. Jeevan Chalke, reviewed by Jeevan Ladhe and by me. Discussion: http://postgr.es/m/CA+TgmobG4ywMzL5oQq2a8YKp8x2p3p1LOMMcGqpS7aekT9+ETA@mail.gmail.com 06 September 2019, 13:05:12 UTC
62724bd Tom Lane 02 September 2019, 18:02:46 UTC Handle corner cases correctly in psql's reconnection logic. After an unexpected connection loss and successful reconnection, psql neglected to resynchronize its internal state about the server, such as server version. Ordinarily we'd be reconnecting to the same server and so this isn't really necessary, but there are scenarios where we do need to update --- one example is where we have a list of possible connection targets and they're not all alike. Define "resynchronize" as including connection_warnings(), so that this case acts the same as \connect. This seems useful; for example, if the server version did change, the user might wish to know that. An attuned user might also notice that the new connection isn't SSL-encrypted, for example, though this approach isn't especially in-your-face about such changes. Although this part is a behavioral change, it only affects interactive sessions, so it should not break any applications. Also, in do_connect, make sure that we desynchronize correctly when abandoning an old connection in non-interactive mode. These problems evidently are the result of people patching only one of the two places where psql deals with connection changes, so insert some cross-referencing comments in hopes of forestalling future bugs of the same ilk. Lastly, in Windows builds, issue codepage mismatch warnings only at startup, not during reconnections. psql's codepage can't change during a reconnect, so complaining about it again seems like useless noise. Peter Billen and Tom Lane. Back-patch to all supported branches. Discussion: https://postgr.es/m/CAMTXbE8e6U=EBQfNSe01Ej17CBStGiudMAGSOPaw-ALxM-5jXg@mail.gmail.com 02 September 2019, 18:02:46 UTC
942b78a Tom Lane 31 August 2019, 18:05:32 UTC Doc: describe the "options" allowed in an ECPG connection target string. These have been there a long time, but their format was never explained in the docs. Per complaint from Yusuke Egashira. Discussion: https://postgr.es/m/848B1649C8A6274AA527C4472CA11EDD5FC70CBE@G01JPEXMBYT02 31 August 2019, 18:05:32 UTC
cf00ca5 Heikki Linnakangas 28 August 2019, 09:55:33 UTC Fix overflow check and comment in GIN posting list encoding. The comment did not match what the code actually did for integers with the 43rd bit set. You get an integer like that, if you have a posting list with two adjacent TIDs that are more than 2^31 blocks apart. According to the comment, we would store that in 6 bytes, with no continuation bit on the 6th byte, but in reality, the code encodes it using 7 bytes, with a continuation bit on the 6th byte as normal. The decoding routine also handled these 7-byte integers correctly, except for an overflow check that assumed that one integer needs at most 6 bytes. Fix the overflow check, and fix the comment to match what the code actually does. Also fix the comment that claimed that there are 17 unused bits in the 64-bit representation of an item pointer. In reality, there are 64-32-11=21. Fitting any item pointer into max 6 bytes was an important property when this was written, because in the old pre-9.4 format, item pointers were stored as plain arrays, with 6 bytes for every item pointer. The maximum of 6 bytes per integer in the new format guaranteed that we could convert any page from the old format to the new format after upgrade, so that the new format was never larger than the old format. But we hardly need to worry about that anymore, and running into that problem during upgrade, where an item pointer is expanded from 6 to 7 bytes such that the data doesn't fit on a page anymore, is implausible in practice anyway. Backpatch to all supported versions. This also includes a little test module to test these large distances between item pointers, without requiring a 16 TB table. It is not backpatched, I'm including it more for the benefit of future development of new posting list formats. Discussion: https://www.postgresql.org/message-id/33bfc20a-5c86-f50c-f5a5-58e9925d05ff%40iki.fi Reviewed-by: Masahiko Sawada, Alexander Korotkov 28 August 2019, 09:58:10 UTC
e9dcbc9 Michael Paquier 28 August 2019, 02:48:33 UTC Disable timeouts when running pg_rewind with online source cluster In this case, the transfer uses a libpq connection, which is subject to the timeout parameters set at system level, and this can make the rewind operation suddenly canceled which is not good for automation. One workaround to such issues would be to use PGOPTIONS to enforce the wanted timeout parameters, but that's annoying, and for example pg_dump, which can run potentially long-running queries disables all types of timeouts. lock_timeout and statement_timeout are the ones which can cause problems now. Note that pg_rewind does not use transactions, so disabling idle_in_transaction_session_timeout is optional, but it feels safer to do so for the future. This is back-patched down to 9.5. idle_in_transaction_session_timeout is only present since 9.6. Author: Alexander Kukushkin Discussion: https://postgr.es/m/CAFh8B=krcVXksxiwVQh1SoY+ziJ-JC=6FcuoBL3yce_40Es5_g@mail.gmail.com Backpatch-through: 9.5 28 August 2019, 02:48:33 UTC
890040b Tom Lane 27 August 2019, 20:37:22 UTC Doc: clarify behavior of standard aggregates for null inputs. Section 4.2.7 says that unless otherwise specified, built-in aggregates ignore rows in which any input is null. This is not true of the JSON aggregates, but it wasn't documented. Fix that. Of the other entries in table 9.55, some were explicit about ignoring nulls, and some weren't; for consistency and self-contained-ness, make them all say it explicitly. Per bug #15884 from Tim Möhlmann. Back-patch to all supported branches. Discussion: https://postgr.es/m/15884-c32d848f787fcae3@postgresql.org 27 August 2019, 20:37:22 UTC
ef47d28 Tom Lane 27 August 2019, 18:44:26 UTC Reject empty names and recursion in config-file include directives. An empty file name or subdirectory name leads join_path_components() to just produce the parent directory name, which leads to weird failures or recursive inclusions. Let's throw a specific error for that. It takes only slightly more code to detect all-blank names, so do so. Also, detect direct recursion, ie a file calling itself. As coded this will also detect recursion via "include_dir '.'", which is perhaps more likely than explicitly including the file itself. Detecting indirect recursion would require API changes for guc-file.l functions, which seems not worth it since extensions might call them. The nesting depth limit will catch such cases eventually, just not with such an on-point error message. In passing, adjust the example usages in postgresql.conf.sample to perhaps eliminate the problem at the source: there's no reason for the examples to suggest that an empty value is valid. Per a trouble report from Brent Bates. Back-patch to 9.5; the issue is old, but the code in 9.4 is enough different that the patch doesn't apply easily, and it doesn't seem worth the trouble to fix there. Ian Barwick and Tom Lane Discussion: https://postgr.es/m/8c8bcbca-3bd9-dc6e-8986-04a5abdef142@2ndquadrant.com 27 August 2019, 18:44:26 UTC
4ed3bda Michael Paquier 27 August 2019, 00:12:14 UTC Fix failure of --jobs with vacuumdb on Windows FD_SETSIZE needs to be declared before winsock2.h, or it is possible to run into buffer overflow issues when using --jobs. This is similar to pgbench's solution done in a23c641. This has been introduced by 71d84ef, and older versions have been using the default value of FD_SETSIZE, defined at 64. While on it, add a missing newline to the previously-added error message. Per buildfarm member jacana, but this impacts all Windows animals running the TAP tests. I have reproduced the failure locally to check the patch. Author: Michael Paquier Reviewed-by: Andrew Dunstan Discussion: https://postgr.es/m/20190826054000.GE7005@paquier.xyz Backpatch-through: 9.5 27 August 2019, 00:12:14 UTC
33066b0 Andrew Dunstan 26 August 2019, 11:44:34 UTC Treat MINGW and MSYS the same in pg_upgrade test script On msys2, 'uname -s' reports a string starting MSYS instead on MINGW as happens on msys1. Treat these both the same way. This reverts 608a710195a4b in favor of a more general solution. Backpatch to all live branches. 26 August 2019, 11:47:41 UTC
a21ec1a Michael Paquier 26 August 2019, 02:14:44 UTC Fix error handling of vacuumdb when running out of fds When trying to use a high number of jobs, vacuumdb has only checked for a maximum number of jobs used, causing confusing failures when running out of file descriptors when the jobs open connections to Postgres. This commit changes the error handling so as we do not check anymore for a maximum number of allowed jobs when parsing the option value with FD_SETSIZE, but check instead if a file descriptor is within the supported range when opening the connections for the jobs so as this is detected at the earliest time possible. Also, improve the error message to give a hint about the number of jobs recommended, using a wording given by the reviewers of the patch. Reported-by: Andres Freund Author: Michael Paquier Reviewed-by: Andres Freund, Álvaro Herrera, Tom Lane Discussion: https://postgr.es/m/20190818001858.ho3ev4z57fqhs7a5@alap3.anarazel.de Backpatch-through: 9.5 26 August 2019, 02:14:44 UTC
65b1cad Tom Lane 25 August 2019, 19:04:04 UTC Avoid platform-specific null pointer dereference in psql. POSIX permits getopt() to advance optind beyond argc when the last argv entry is an option that requires an argument and hasn't got one. It seems that no major platforms actually do that, but musl does, so that something like "psql -f" would crash with that libc. Add a check that optind is in range before trying to look at the possibly-bogus option. Report and fix by Quentin Rameau. Back-patch to all supported branches. Discussion: https://postgr.es/m/20190825100617.GA6087@fifth.space 25 August 2019, 19:04:04 UTC
9f4bf6d Michael Paquier 22 August 2019, 00:59:44 UTC Doc: Remove mention to "Visual Studio Express 2019" The "Express" flavor of Visual Studio exists up to 2017, and the documentation referred to "Express" for Visual Studio 2019. Author: Takuma Hoshiai Discussion: https://postgr.es/m/20190820120231.f905542e685140258ca73d82@sraoss.co.jp Backpatch-through: 9.4 22 August 2019, 00:59:44 UTC
aad9bf3 Alvaro Herrera 21 August 2019, 15:12:44 UTC Fix typo In early development patches, "replication origins" were called "identifiers"; almost everything was renamed, but these references to the old terminology went unnoticed. Reported-by: Craig Ringer 21 August 2019, 15:12:44 UTC
5a32fcd Alvaro Herrera 20 August 2019, 20:04:09 UTC Fix bogus comment Author: Alexander Lakhin Discussion: https://postgr.es/m/20190819072244.GE18166@paquier.xyz 20 August 2019, 20:04:09 UTC
7ffd4f3 Michael Paquier 20 August 2019, 04:46:19 UTC Doc: Fix various typos All those fixes are already included on HEAD thanks to for example c96581a and 66bde49, and have gone missing on back-branches. Author: Alexander Lakhin, Liudmila Mantrova Discussion: https://postgr.es/m/CAEkD-mDJHV3bhgezu3MUafJLoAKsOOT86+wHukKU8_NeiJYhLQ@mail.gmail.com Backpatch-through: 9.4 20 August 2019, 04:46:19 UTC
c511d36 Tom Lane 18 August 2019, 21:11:58 UTC Disallow changing an inherited column's type if not all parents changed. If a table inherits from multiple unrelated parents, we must disallow changing the type of a column inherited from multiple such parents, else it would be out of step with the other parents. However, it's possible for the column to ultimately be inherited from just one common ancestor, in which case a change starting from that ancestor should still be allowed. (I would not be excited about preserving that option, were it not that we have regression test cases exercising it already ...) It's slightly annoying that this patch looks different from the logic with the same end goal in renameatt(), and more annoying that it requires an extra syscache lookup to make the test. However, the recursion logic is quite different in the two functions, and a back-patched bug fix is no place to be trying to unify them. Per report from Manuel Rigger. Back-patch to 9.5. The bug exists in 9.4 too (and doubtless much further back); but the way the recursion is done in 9.4 is a good bit different, so that substantial refactoring would be needed to fix it in 9.4. I'm disinclined to do that, or risk introducing new bugs, for a bug that has escaped notice for this long. Discussion: https://postgr.es/m/CA+u7OA4qogDv9rz1HAb-ADxttXYPqQdUdPY_yd4kCzywNxRQXA@mail.gmail.com 18 August 2019, 21:11:58 UTC
cb0c79a Tom Lane 16 August 2019, 00:04:19 UTC Prevent possible double-free when update trigger returns old tuple. This is a variant of the problem fixed in commit 25b692568, which unfortunately we failed to detect at the time. If an update trigger returns the "old" tuple, as it's entitled to do, then a subsequent iteration of the loop in ExecBRUpdateTriggers would have "oldtuple" equal to "trigtuple" and would fail to notice that it shouldn't free that. In addition to fixing the code, extend the test case added by 25b692568 so that it covers multiple-trigger-iterations cases. This problem does not manifest in v12/HEAD, as a result of the relevant code having been largely rewritten for slotification. However, include the test case into v12/HEAD anyway, since this is clearly an area that someone could break again in future. Per report from Piotr Gabriel Kosinski. Back-patch into all supported branches, since the bug seems quite old. Diagnosis and code fix by Thomas Munro, test case by me. Discussion: https://postgr.es/m/CAFMLSdP0rd7LqC3j-H6Fh51FYSt5A10DDh-3=W4PPc4LLUQ8YQ@mail.gmail.com 16 August 2019, 00:04:19 UTC
1ab92aa Tom Lane 15 August 2019, 15:14:26 UTC Doc: improve documentation about postgresql.auto.conf. Clarify what external tools can do to this file, and add a bit of detail about what ALTER SYSTEM itself does. Discussion: https://postgr.es/m/aed6cc9f-98f3-2693-ac81-52bb0052307e@2ndquadrant.com 15 August 2019, 15:14:26 UTC
29f9b18 Tom Lane 14 August 2019, 19:09:20 UTC Fix ALTER SYSTEM to cope with duplicate entries in postgresql.auto.conf. ALTER SYSTEM itself normally won't make duplicate entries (although up till this patch, it was possible to confuse it by writing case variants of a GUC's name). However, if some external tool has appended entries to the file, that could result in duplicate entries for a single GUC name. In such a situation, ALTER SYSTEM did exactly the wrong thing, because it replaced or removed only the first matching entry, leaving the later one(s) still there and hence still determining the active value. This patch fixes that by making ALTER SYSTEM sweep through the file and remove all matching entries, then (if not ALTER SYSTEM RESET) append the new setting to the end. This means entries will be in order of last setting rather than first setting, but that shouldn't hurt anything. Also, make the comparisons case-insensitive so that the right things happen if you do, say, ALTER SYSTEM SET "TimeZone" = 'whatever'. This has been broken since ALTER SYSTEM was invented, so back-patch to all supported branches. Ian Barwick, with minor mods by me Discussion: https://postgr.es/m/aed6cc9f-98f3-2693-ac81-52bb0052307e@2ndquadrant.com 14 August 2019, 19:09:20 UTC
c568584 Tom Lane 13 August 2019, 20:57:59 UTC Un-break pg_dump for pre-8.3 source servers. Commit 07b39083c inserted an unconditional reference to pg_opfamily, which of course fails on servers predating that catalog. Fortunately, the case it's trying to solve can't occur on such old servers (AFAIK). Hence, just skip the additional code when the source predates 8.3. Per bug #15955 from sly. Back-patch to all supported branches, like the previous patch. Discussion: https://postgr.es/m/15955-1daa2e676e903d87@postgresql.org 13 August 2019, 20:57:59 UTC
72bdf0f Peter Eisentraut 12 August 2019, 19:20:14 UTC Fix compiler warning With some newer gcc versions (8 and 9) you get a -Wformat-overflow warning here. In PG11 and later this was already fixed. Since it's trivial, backport it to get the older branches building without warnings. 12 August 2019, 19:24:07 UTC
bae875d Tom Lane 07 August 2019, 22:09:28 UTC Doc: document permissions required for ANALYZE. VACUUM's reference page had this text, but ANALYZE's didn't. That's a clear oversight given that section 5.7 explicitly delegates the responsibility to define permissions requirements to the individual commands' man pages. Per gripe from Isaac Morland. Back-patch to all supported branches. Discussion: https://postgr.es/m/CAMsGm5fp3oBUs-2iRfii0iEO=fZuJALVyM2zJLhNTjG34gpAVQ@mail.gmail.com 07 August 2019, 22:09:28 UTC
fd298cd Heikki Linnakangas 07 August 2019, 09:40:49 UTC Fix predicate-locking of HOT updated rows. In serializable mode, heap_hot_search_buffer() incorrectly acquired a predicate lock on the root tuple, not the returned tuple that satisfied the visibility checks. As explained in README-SSI, the predicate lock does not need to be copied or extended to other tuple versions, but for that to work, the correct, visible, tuple version must be locked in the first place. The original SSI commit had this bug in it, but it was fixed back in 2013, in commit 81fbbfe335. But unfortunately, it was reintroduced a few months later in commit b89e151054. Wising up from that, add a regression test to cover this, so that it doesn't get reintroduced again. Also, move the code that sets 't_self', so that it happens at the same time that the other HeapTuple fields are set, to make it more clear that all the code in the loop operate on the "current" tuple in the chain, not the root tuple. Bug spotted by Andres Freund, analysis and original fix by Thomas Munro, test case and some additional changes to the fix by Heikki Linnakangas. Backpatch to all supported versions (9.4). Discussion: https://www.postgresql.org/message-id/20190731210630.nqhszuktygwftjty%40alap3.anarazel.de 07 August 2019, 09:41:31 UTC
1de3e05 Michael Paquier 07 August 2019, 09:17:57 UTC Fix some incorrect parsing of time with time zone strings When parsing a timetz string with a dynamic timezone abbreviation or a timezone not specified, it was possible to generate incorrect timestamps based on a date which uses some non-initialized variables if the input string did not specify fully a date to parse. This is already checked when a full timezone spec is included in the input string, but the two other cases mentioned above missed the same checks. This gets fixed by generating an error as this input is invalid, or in short when a date is not fully specified. Valgrind was complaining about this problem. Bug: #15910 Author: Alexander Lakhin Discussion: https://postgr.es/m/15910-2eba5106b9aa0c61@postgresql.org Backpatch-through: 9.4 07 August 2019, 09:17:57 UTC
ced272d Tom Lane 06 August 2019, 22:04:52 UTC Fix intarray's GiST opclasses to not fail for empty arrays with <@. contrib/intarray considers "arraycol <@ constant-array" to be indexable, but its GiST opclass code fails to reliably find index entries for empty array values (which of course should trivially match such queries). This is because the test condition to see whether we should descend through a non-leaf node is wrong. Unfortunately, empty array entries could be anywhere in the index, as these index opclasses are currently designed. So there's no way to fix this except by lobotomizing <@ indexscans to scan the whole index ... which is what this patch does. That's pretty unfortunate: the performance is now actually worse than a seqscan, in most cases. We'd be better off to remove <@ from the GiST opclasses entirely, and perhaps a future non-back-patchable patch will do so. In the meantime, applications whose performance is adversely impacted have a couple of options. They could switch to a GIN index, which doesn't have this bug, or they could replace "arraycol <@ constant-array" with "arraycol <@ constant-array AND arraycol && constant-array". That will provide about the same performance as before, and it will find all non-empty subsets of the given constant-array, which is all that could reliably be expected of the query before. While at it, add some more regression test cases to improve code coverage of contrib/intarray. In passing, adjust resize_intArrayType so that when it's returning an empty array, it uses construct_empty_array for that rather than cowboy hacking on the input array. While the hack produces an array that looks valid for most purposes, it isn't bitwise equal to empty arrays produced by other code paths, which could have subtle odd effects. I don't think this code path is performance-critical enough to justify such shortcuts. (Back-patch this part only as far as v11; before commit 01783ac36 we were not careful about this in other intarray code paths either.) Back-patch the <@ fixes to all supported versions, since this was broken from day one. Patch by me; thanks to Alexander Korotkov for review. Discussion: https://postgr.es/m/458.1565114141@sss.pgh.pa.us 06 August 2019, 22:04:52 UTC
167e535 Tom Lane 05 August 2019, 21:20:40 UTC Stamp 9.5.19. 05 August 2019, 21:20:40 UTC
e3d8c9a Tom Lane 05 August 2019, 15:49:14 UTC Last-minute updates for release notes. Security: CVE-2019-10208, CVE-2019-10209 05 August 2019, 15:49:14 UTC
752fa3d Noah Misch 05 August 2019, 14:48:41 UTC Require the schema qualification in pg_temp.type_name(arg). Commit aa27977fe21a7dfa4da4376ad66ae37cb8f0d0b5 introduced this restriction for pg_temp.function_name(arg); do likewise for types created in temporary schemas. Programs that this breaks should add "pg_temp." schema qualification or switch to arg::type_name syntax. Back-patch to 9.4 (all supported versions). Reviewed by Tom Lane. Reported by Tom Lane. Security: CVE-2019-10208 05 August 2019, 14:48:45 UTC
back to top