commit : e0fb7a2ce39f25cbbbe50c95aebdab1ee3beff23 author : Tom Lane <firstname.lastname@example.org> date : Mon, 6 Aug 2018 16:13:40 -0400 committer: Tom Lane <email@example.com> date : Mon, 6 Aug 2018 16:13:40 -0400
commit : 50043c87dfaf8e554e792df15ae8ef1fc5df9632 author : Peter Eisentraut <firstname.lastname@example.org> date : Mon, 6 Aug 2018 19:30:02 +0200 committer: Peter Eisentraut <email@example.com> date : Mon, 6 Aug 2018 19:30:02 +0200
Source-Git-URL: https://git.postgresql.org/git/pgtranslation/messages.git Source-Git-Hash: e4d7d445c8afaf0fe2bccc834027d8893e2a7e61
Last-minute updates for release notes.
commit : ebeb8d53710ea140dd00eb6506cbe50db4e11dce author : Tom Lane <firstname.lastname@example.org> date : Mon, 6 Aug 2018 13:13:41 -0400 committer: Tom Lane <email@example.com> date : Mon, 6 Aug 2018 13:13:41 -0400
Security: CVE-2018-10915, CVE-2018-10925
Fix failure to reset libpq's state fully between connection attempts.
commit : 243de06be96d6001d01f2ec7c4573aad8b657195 author : Tom Lane <firstname.lastname@example.org> date : Mon, 6 Aug 2018 10:53:35 -0400 committer: Tom Lane <email@example.com> date : Mon, 6 Aug 2018 10:53:35 -0400
The logic in PQconnectPoll() did not take care to ensure that all of a PGconn's internal state variables were reset before trying a new connection attempt. If we got far enough in the connection sequence to have changed any of these variables, and then decided to try a new server address or server name, the new connection might be completed with some state that really only applied to the failed connection. While this has assorted bad consequences, the only one that is clearly a security issue is that password_needed didn't get reset, so that if the first server asked for a password and the second didn't, PQconnectionUsedPassword() would return an incorrect result. This could be leveraged by unprivileged users of dblink or postgres_fdw to allow them to use server-side login credentials that they should not be able to use. Other notable problems include the possibility of forcing a v2-protocol connection to a server capable of supporting v3, or overriding "sslmode=prefer" to cause a non-encrypted connection to a server that would have accepted an encrypted one. Those are certainly bugs but it's harder to paint them as security problems in themselves. However, forcing a v2-protocol connection could result in libpq having a wrong idea of the server's standard_conforming_strings setting, which opens the door to SQL-injection attacks. The extent to which that's actually a problem, given the prerequisite that the attacker needs control of the client's connection parameters, is unclear. These problems have existed for a long time, but became more easily exploitable in v10, both because it introduced easy ways to force libpq to abandon a connection attempt at a late stage and then try another one (rather than just giving up), and because it provided an easy way to specify multiple target hosts. Fix by rearranging PQconnectPoll's state machine to provide centralized places to reset state properly when moving to a new target host or when dropping and retrying a connection to the same host. Tom Lane, reviewed by Noah Misch. Our thanks to Andrew Krasichkov for finding and reporting the problem. Security: CVE-2018-10915
Release notes for 10.5, 9.6.10, 9.5.14, 9.4.19, 9.3.24.
commit : c1b34c80894bf77c38f2ef55123e7cd2c5cb5fc2 author : Tom Lane <firstname.lastname@example.org> date : Sun, 5 Aug 2018 16:38:43 -0400 committer: Tom Lane <email@example.com> date : Sun, 5 Aug 2018 16:38:43 -0400
Doc: fix incorrectly stated argument list for pgcrypto's hmac() function.
commit : 716f645d12aabcd5605d4d9092be2a13b4481729 author : Tom Lane <firstname.lastname@example.org> date : Sun, 5 Aug 2018 13:03:42 -0400 committer: Tom Lane <email@example.com> date : Sun, 5 Aug 2018 13:03:42 -0400
The bytea variant takes (bytea, bytea, text). Per unsigned report. Discussion: https://firstname.lastname@example.org
Reset properly errno before calling write()
commit : 69599cc49e7cc48f180e49322aea00c1ec634388 author : Michael Paquier <email@example.com> date : Sun, 5 Aug 2018 05:32:54 +0900 committer: Michael Paquier <firstname.lastname@example.org> date : Sun, 5 Aug 2018 05:32:54 +0900
6cb3372 enforces errno to ENOSPC when less bytes than what is expected have been written when it is unset, though it forgot to properly reset errno before doing a system call to write(), causing errno to potentially come from a previous system call. Reported-by: Tom Lane Author: Michael Paquier Reviewed-by: Tom Lane Discussion: https://email@example.com
Add table relcache invalidation to index builds.
commit : 0229e087df2ac050f53140fd7497d0e70943d16f author : Peter Geoghegan <firstname.lastname@example.org> date : Fri, 3 Aug 2018 14:44:26 -0700 committer: Peter Geoghegan <email@example.com> date : Fri, 3 Aug 2018 14:44:26 -0700
It's necessary to make sure that owning tables have a relcache invalidation prior to advancing the command counter to make newly-entered catalog tuples for the index visible. inval.c must be able to maintain the consistency of the local caches in the event of transaction abort. There is usually only a problem when CREATE INDEX transactions abort, since there is a generic invalidation once we reach index_update_stats(). This bug is of long standing. Problems were made much more likely by the addition of parallel CREATE INDEX (commit 9da0cc35284), but it is strongly suspected that similar problems can be triggered without involving plan_create_index_workers(). (plan_create_index_workers() triggers a relcache build or rebuild, which previously only happened in rare edge cases.) Author: Peter Geoghegan Reported-By: Luca Ferrari Diagnosed-By: Andres Freund Reviewed-By: Andres Freund Discussion: https://postgr.es/m/CAKoxK+5fVodiCtMsXKV_1YAKXbzwSfp7DgDqUmcUAzeAhf=HEQ@mail.gmail.com Backpatch: 9.3-
pg_upgrade: Add SYSTEMQUOTE for Windows paths with spaces
commit : dfc71a1b2567f9d43ba53fce6da4e381c0571c7c author : Bruce Momjian <firstname.lastname@example.org> date : Tue, 31 Jul 2018 19:06:32 -0400 committer: Bruce Momjian <email@example.com> date : Tue, 31 Jul 2018 19:06:32 -0400
Another fix for commit 244142d32afd02e7408a2ef1f249b00393983822. We added SYSTEMQUOTE to the win32 popen() compatibility function in PG 9.4. Backpatch-through: 9.3 only
pg_upgrade: fix --check for live source server checks
commit : a1d383ab57842e1c52d0824a07d35339359e13b9 author : Bruce Momjian <firstname.lastname@example.org> date : Tue, 31 Jul 2018 18:10:06 -0400 committer: Bruce Momjian <email@example.com> date : Tue, 31 Jul 2018 18:10:06 -0400
Fix for commit 244142d32afd02e7408a2ef1f249b00393983822. Backpatch-through: 9.3
Further fixes for quoted-list GUC values in pg_dump and ruleutils.c.
commit : 461e2e433bd622c3761987df8653a682483b7acc author : Tom Lane <firstname.lastname@example.org> date : Tue, 31 Jul 2018 13:00:08 -0400 committer: Tom Lane <email@example.com> date : Tue, 31 Jul 2018 13:00:08 -0400
Commits 742869946 et al turn out to be a couple bricks shy of a load. We were dumping the stored values of GUC_LIST_QUOTE variables as they appear in proconfig or setconfig catalog columns. However, although that quoting rule looks a lot like SQL-identifier double quotes, there are two critical differences: empty strings ("") are legal, and depending on which variable you're considering, values longer than NAMEDATALEN might be valid too. So the current technique fails altogether on empty-string list entries (as reported by Steven Winfield in bug #15248) and it also risks truncating file pathnames during dump/reload of GUC values that are lists of pathnames. To fix, split the stored value without any downcasing or truncation, and then emit each element as a SQL string literal. This is a tad annoying, because we now have three copies of the comma-separated-string splitting logic in varlena.c as well as a fourth one in dumputils.c. (Not to mention the randomly-different-from-those splitting logic in libpq...) I looked at unifying these, but it would be rather a mess unless we're willing to tweak the API definitions of SplitIdentifierString, SplitDirectoriesString, or both. That might be worth doing in future; but it seems pretty unsafe for a back-patched bug fix, so for now accept the duplication. Back-patch to all supported branches, as the previous fix was. Discussion: https://firstname.lastname@example.org
Fix earthdistance test suite function name typo.
commit : 003132d178e7a13fbdaf96781d2c43f209b528d0 author : Noah Misch <email@example.com> date : Sun, 29 Jul 2018 12:02:07 -0700 committer: Noah Misch <firstname.lastname@example.org> date : Sun, 29 Jul 2018 12:02:07 -0700
Affected test queries have been testing the wrong thing since their introduction in commit 4c1383efd132e4f532213c8a8cc63a455f55e344. Back-patch to 9.3 (all supported versions).
Document security implications of qualified names.
commit : c0550994489d76427b2b3301841f65161c3e70ad author : Noah Misch <email@example.com> date : Sat, 28 Jul 2018 20:08:01 -0700 committer: Noah Misch <firstname.lastname@example.org> date : Sat, 28 Jul 2018 20:08:01 -0700
Commit 5770172cb0c9df9e6ce27c507b449557e5b45124 documented secure schema usage, and that advice suffices for using unqualified names securely. Document, in typeconv-func primarily, the additional issues that arise with qualified names. Back-patch to 9.3 (all supported versions). Reviewed by Jonathan S. Katz. Discussion: https://postgr.es/m/20180721012446.GA1840594@rfd.leadboat.com
pg_upgrade: check for clean server shutdowns
commit : a5c84e0b7f38ebc5115591d7b0d4ddc706d21c41 author : Bruce Momjian <email@example.com> date : Sat, 28 Jul 2018 15:01:55 -0400 committer: Bruce Momjian <firstname.lastname@example.org> date : Sat, 28 Jul 2018 15:01:55 -0400
Previously pg_upgrade checked for the pid file and started/stopped the server to force a clean shutdown. However, "pg_ctl -m immediate" removes the pid file but doesn't do a clean shutdown, so check pg_controldata for a clean shutdown too. Diagnosed-by: Vimalraj A Discussion: https://postgr.es/m/CAFKBAK5e4Q-oTUuPPJ56EU_d2Rzodq6GWKS3ncAk3xo7hAsOZg@mail.gmail.com Backpatch-through: 9.3
Further portability hacking in pg_upgrade's test script.
commit : b782b7c57fe84762a9065f59b7ca52babe281fcb author : Tom Lane <email@example.com> date : Sat, 21 Jul 2018 15:40:52 -0400 committer: Tom Lane <firstname.lastname@example.org> date : Sat, 21 Jul 2018 15:40:52 -0400
I blew the dust off a Bourne shell (file date 1996, yea verily) and tried to run test.sh with it. It mostly worked, but I found that the temp-directory creation code introduced by commit be76a6d39 was not compatible, for a couple of reasons: this shell thinks "set -e" should force an exit if a command within backticks fails, and it also thinks code within braces should be executed by a sub-shell, meaning that variable settings don't propagate back up to the parent shell. In view of Victor Wagner's report that Solaris is still using pre-POSIX shells, seems like we oughta make this case work. It's not like the code is any less idiomatic this way; the prior coding technique appeared nowhere else. (There is a remaining bash-ism here, which is that $RANDOM doesn't do what the code hopes in non-bash shells. But the use of $$ elsewhere in that path should be enough to ensure uniqueness and some amount of randomness, so I think it's okay as-is.) Back-patch to all supported branches, as the previous commit was. Discussion: https://email@example.com
Fix misc typos, mostly in comments.
commit : b0a7a41db53ef82aab340d62183bd047a386841c author : Heikki Linnakangas <firstname.lastname@example.org> date : Mon, 9 Jul 2018 16:10:44 +0300 committer: Heikki Linnakangas <email@example.com> date : Mon, 9 Jul 2018 16:10:44 +0300
A collection of typos I happened to spot while reading code, as well as grepping for common mistakes. Backpatch to all supported versions, as applicable, to avoid conflicts when backporting other commits in the future.
Fix crash in contrib/ltree's lca() function for empty input array.
commit : cbbe75fe67195d9ee3efb2ea7af216c37a521cbf author : Tom Lane <firstname.lastname@example.org> date : Fri, 13 Jul 2018 18:45:30 -0400 committer: Tom Lane <email@example.com> date : Fri, 13 Jul 2018 18:45:30 -0400
lca_inner() wasn't prepared for the possibility of getting no inputs. Fix that, and make some cosmetic improvements to the code while at it. Also, I thought the documentation of this function as returning the "longest common prefix" of the paths was entirely misleading; it really returns a path one shorter than the longest common prefix, for the typical definition of "prefix". Don't use that term in the docs, and adjust the examples to clarify what really happens. This has been broken since its beginning, so back-patch to all supported branches. Per report from Hailong Li. Thanks to Pierre Ducroquet for diagnosing and for the initial patch, though I whacked it around some and added test cases. Discussion: https://firstname.lastname@example.org
Fix inadequate buffer locking in FSM and VM page re-initialization.
commit : 0cf3363c01104cd7a0388a3e01a533f21872d011 author : Tom Lane <email@example.com> date : Fri, 13 Jul 2018 11:52:50 -0400 committer: Tom Lane <firstname.lastname@example.org> date : Fri, 13 Jul 2018 11:52:50 -0400
When reading an existing FSM or VM page that was found to be corrupt by the buffer manager, the code applied PageInit() to reinitialize the page, but did so without any locking. There is thus a hazard that two backends might concurrently do PageInit, which in itself would still be OK, but the slower one might then zero over subsequent data changes applied by the faster one. Even that is unlikely to be fatal; but it's not desirable, so add locking to prevent it. This does not add any locking overhead in the normal code path where the page is OK. It's not immediately obvious that that's safe, but I believe it is, for reasons explained in the added comments. Problem noted by R P Asim. It's been like this for a long time, so back-patch to all supported branches. Discussion: https://postgr.es/m/CANXE4Te4G0TGq6cr0-TvwP0H4BNiK_-hB5gHe8mF+nz0mcYfMQ@mail.gmail.com
docs: Remove "New" description of the libpqxx interface
commit : a3445ccb774c673612863cfa5e0714eeba48eb0e author : Bruce Momjian <email@example.com> date : Fri, 13 Jul 2018 11:16:55 -0400 committer: Bruce Momjian <firstname.lastname@example.org> date : Fri, 13 Jul 2018 11:16:55 -0400
Doc: minor improvement in pl/pgsql FETCH/MOVE documentation.
commit : 2e7a25c1dcb7acb9d1138934cade1f1a7e6fe690 author : Tom Lane <email@example.com> date : Thu, 12 Jul 2018 12:28:43 -0400 committer: Tom Lane <firstname.lastname@example.org> date : Thu, 12 Jul 2018 12:28:43 -0400
Explain that you can use any integer expression for the "count" in pl/pgsql's versions of FETCH/MOVE, unlike the SQL versions which only allow a constant. Remove the duplicate version of this para under MOVE. I don't see a good reason to maintain two identical paras when we just said that MOVE works exactly like FETCH. Per Pavel Stehule, though I didn't use his text. Discussion: https://postgr.es/m/CAFj8pRAcvSXcNdUGx43bOK1e3NNPbQny7neoTLN42af+8MYWEA@mail.gmail.com
Avoid emitting a bogus WAL record when recycling an all-zero btree page.
commit : e8fe3bb23003028760948f829f7a701cdd66dbf2 author : Tom Lane <email@example.com> date : Mon, 9 Jul 2018 19:26:19 -0400 committer: Tom Lane <firstname.lastname@example.org> date : Mon, 9 Jul 2018 19:26:19 -0400
Commit fafa374f2 caused _bt_getbuf() to possibly emit a WAL record for a page that it was about to recycle. However, it failed to distinguish all-zero pages from dead pages, which is important because only the latter have valid btpo.xact values, or indeed any special space at all. Recycling an all-zero page with XLogStandbyInfoActive() enabled therefore led to an Assert failure, or to emission of a WAL record containing a bogus cutoff XID, which might lead to unnecessary query cancellations on hot standby servers. Per reports from Antonin Houska and 自己. Amit Kapila was first to propose this fix, and Robert Haas, myself, and Kyotaro Horiguchi reviewed it at various times. This is an old bug, so back-patch to all supported branches. Discussion: https://postgr.es/m/2628.1474272158@localhost Discussion: https://postgr.es/m/48875502.f4a0.1635f0c27b0.Coremail.email@example.com
Prevent accidental linking of system-supplied copies of libpq.so etc.
commit : f6f75539d24772126a975256b8df9f8d57b07851 author : Tom Lane <firstname.lastname@example.org> date : Mon, 9 Jul 2018 17:23:32 -0400 committer: Tom Lane <email@example.com> date : Mon, 9 Jul 2018 17:23:32 -0400
Back-patch commit dddfc4cb2, which broke LDFLAGS and related Makefile variables into two parts, one for within-build-tree library references and one for external libraries, to ensure that the order of -L flags has all of the former before all of the latter. This turns out to fix a problem recently noted on buildfarm member peripatus, that we attempted to incorporate code from libpgport.a into a shared library. That will fail on platforms that are sticky about putting non-PIC code into shared libraries. (It's quite surprising we hadn't seen such failures before, since the code in question has been like that for a long time.) I think that peripatus' problem could have been fixed with just a subset of this patch; but since the previous issue of accidentally linking to the wrong copy of a Postgres shlib seems likely to bite people in the field, let's just back-patch the whole change. Now that commit dddfc4cb2 has survived some beta testing, I'm less afraid to back-patch it than I was at the time. This also fixes undesired inclusion of "-DFRONTEND" in pg_config's CPPFLAGS output (in 9.6 and up) and undesired inclusion of "-L../../src/common" in its LDFLAGS output (in all supported branches). Back-patch to v10 and older branches; this is already in v11. Discussion: https://firstname.lastname@example.org
Prevent references to invalid relation pages after fresh promotion
commit : 56535dcdc9e2470fd4aadae2fc76f771819c3b7a author : Michael Paquier <email@example.com> date : Thu, 5 Jul 2018 10:48:03 +0900 committer: Michael Paquier <firstname.lastname@example.org> date : Thu, 5 Jul 2018 10:48:03 +0900
If a standby crashes after promotion before having completed its first post-recovery checkpoint, then the minimal recovery point which marks the LSN position where the cluster is able to reach consistency may be set to a position older than the first end-of-recovery checkpoint while all the WAL available should be replayed. This leads to the instance thinking that it contains inconsistent pages, causing a PANIC and a hard instance crash even if all the WAL available has not been replayed for certain sets of records replayed. When in crash recovery, minRecoveryPoint is expected to always be set to InvalidXLogRecPtr, which forces the recovery to replay all the WAL available, so this commit makes sure that the local copy of minRecoveryPoint from the control file is initialized properly and stays as it is while crash recovery is performed. Once switching to archive recovery or if crash recovery finishes, then the local copy minRecoveryPoint can be safely updated. Pavan Deolasee has reported and diagnosed the failure in the first place, and the base fix idea to rely on the local copy of minRecoveryPoint comes from Kyotaro Horiguchi, which has been expanded into a full-fledged patch by me. The test included in this commit has been written by Álvaro Herrera and Pavan Deolasee, which I have modified to make it faster and more reliable with sleep phases. Backpatch down to all supported versions where the bug appears, aka 9.3 which is where the end-of-recovery checkpoint is not run by the startup process anymore. The test gets easily supported down to 10, still it has been tested on all branches. Reported-by: Pavan Deolasee Diagnosed-by: Pavan Deolasee Reviewed-by: Pavan Deolasee, Kyotaro Horiguchi Author: Michael Paquier, Kyotaro Horiguchi, Pavan Deolasee, Álvaro Herrera Discussion: https://postgr.es/m/CABOikdPOewjNL=05K5CbNMxnNtXnQjhTx2F--4p4ruorCjukbA@mail.gmail.com
Improve the performance of relation deletes during recovery.
commit : 7ffe0127e5f104fe932146c4e6c8fd03c5638df7 author : Fujii Masao <email@example.com> date : Thu, 5 Jul 2018 02:21:15 +0900 committer: Fujii Masao <firstname.lastname@example.org> date : Thu, 5 Jul 2018 02:21:15 +0900
When multiple relations are deleted at the same transaction, the files of those relations are deleted by one call to smgrdounlinkall(), which leads to scan whole shared_buffers only one time. OTOH, previously, during recovery, smgrdounlink() (not smgrdounlinkall()) was called for each file to delete, which led to scan shared_buffers multiple times. Obviously this could cause to increase the WAL replay time very much especially when shared_buffers was huge. To alleviate this situation, this commit changes the recovery so that it also calls smgrdounlinkall() only one time to delete multiple relation files. This is just fix for oversight of commit 279628a0a7, not new feature. So, per discussion on pgsql-hackers, we concluded to backpatch this to all supported versions. Author: Fujii Masao Reviewed-by: Michael Paquier, Andres Freund, Thomas Munro, Kyotaro Horiguchi, Takayuki Tsunakawa Discussion: https://postgr.es/m/CAHGQGwHVQkdfDqtvGVkty+19cQakAydXn1etGND3X0PHbZ3email@example.com
Fix libpq example programs
commit : 7fbbbe1efbfb0cb55b97982f7dbefe68682e9e2d author : Peter Eisentraut <firstname.lastname@example.org> date : Sun, 1 Jul 2018 14:06:40 +0200 committer: Peter Eisentraut <email@example.com> date : Sun, 1 Jul 2018 14:06:40 +0200
When these programs call pg_catalog.set_config, they need to check for PGRES_TUPLES_OK instead of PGRES_COMMAND_OK. Fix for 5770172cb0c9df9e6ce27c507b449557e5b45124. Reported-by: Ideriha, Takeshi <firstname.lastname@example.org>
Replace search.cpan.org with metacpan.org
commit : 6acb4e89fe472e74bcbb3d3b997cccef6c026be9 author : Michael Paquier <email@example.com> date : Fri, 29 Jun 2018 22:18:24 +0900 committer: Michael Paquier <firstname.lastname@example.org> date : Fri, 29 Jun 2018 22:18:24 +0900
search.cpan.org has been EOL'd, with metacpan.org being the official replacement to which URLs now redirect. Update links to match the new URL. Also update links to CPAN to use https as it will redirect from http. Author: Daniel Gustafsson Discussion: https://postgr.es/m/B74C0219-6BA9-46E1-A524-5B9E8CD3BDB3@yesql.se
Fix documentation bug related to backup history file.
commit : 833397e73e2e8d8e37aa38b31e00320161bb6ff8 author : Fujii Masao <email@example.com> date : Wed, 27 Jun 2018 00:45:21 +0900 committer: Fujii Masao <firstname.lastname@example.org> date : Wed, 27 Jun 2018 00:45:21 +0900
The backup history file has been no longer necessary for recovery since the version 9.0. It's now basically just for informational purpose. But previously the documentations still described that a recovery requests the backup history file to proceed. The commit fixes this documentation bug. Back-patch to all supported versions. Author: Yugo Nagata Reviewed-by: Kyotaro Horiguchi Discussion: https://email@example.com
Add PGTYPESchar_free() to avoid cross-module problems on Windows.
commit : edabd8f5a4249b95db7421722f88e156c10c8a8e author : Thomas Munro <firstname.lastname@example.org> date : Mon, 18 Jun 2018 18:33:53 +1200 committer: Thomas Munro <email@example.com> date : Mon, 18 Jun 2018 18:33:53 +1200
On Windows, it is sometimes important for corresponding malloc() and free() calls to be made from the same DLL, since some build options can result in multiple allocators being active at the same time. For that reason we already provided PQfreemem(). This commit adds a similar function for freeing string results allocated by the pgtypes library. Author: Takayuki Tsunakawa Reviewed-by: Kyotaro Horiguchi Discussion: https://postgr.es/m/0A3221C70F24FB45833433255569204D1F8AD5D6%40G01JPEXMBYT05
Move RecoveryLockList into a hash table.
commit : 12f7d91994d15d362384be46eec92498bdc001c6 author : Thomas Munro <firstname.lastname@example.org> date : Tue, 26 Jun 2018 18:23:17 +1200 committer: Thomas Munro <email@example.com> date : Tue, 26 Jun 2018 18:23:17 +1200
Standbys frequently need to release all locks held by a given xid. Instead of searching one big list linearly, let's create one list per xid and put them in a hash table, so we can find what we need in O(1) time. Earlier analysis and a prototype were done by David Rowley, though this isn't his patch. Back-patch all the way. Author: Thomas Munro Diagnosed-by: David Rowley, Andres Freund Reviewed-by: Andres Freund, Tom Lane, Robert Haas Discussion: https://postgr.es/m/CAEepm%3D1mL0KiQ2KJ4yuPpLGX94a4Ns_W6TL4EGRouxWibu56pA%40mail.gmail.com Discussion: https://postgr.es/m/CAKJS1f9vJ841HY%3DwonnLVbfkTWGYWdPN72VMxnArcGCjF3SywA%40mail.gmail.com
Address set of issues with errno handling
commit : f53ed82b7feeb1eee7388a24aa792e1d1b33e650 author : Michael Paquier <firstname.lastname@example.org> date : Mon, 25 Jun 2018 10:30:59 +0900 committer: Michael Paquier <email@example.com> date : Mon, 25 Jun 2018 10:30:59 +0900
System calls mixed up in error code paths are causing two issues which several code paths have not correctly handled: 1) For write() calls, sometimes the system may return less bytes than what has been written without errno being set. Some paths were careful enough to consider that case, and assumed that errno should be set to ENOSPC, other calls missed that. 2) errno generated by a system call is overwritten by other system calls which may succeed once an error code path is taken, causing what is reported to the user to be incorrect. This patch uses the brute-force approach of correcting all those code paths. Some refactoring could happen in the future, but this is let as future work, which is not targeted for back-branches anyway. Author: Michael Paquier Reviewed-by: Ashutosh Sharma Discussion: https://postgr.es/m/20180622061535.GD5215@paquier.xyz
doc: adjust order of NUMERIC arguments to match syntax
commit : 0a140ab32f4993917f81f07531752c41246fcac1 author : Bruce Momjian <firstname.lastname@example.org> date : Sun, 24 Jun 2018 18:07:00 -0400 committer: Bruce Momjian <email@example.com> date : Sun, 24 Jun 2018 18:07:00 -0400
Specifically, mention precision before scale Reported-by: firstname.lastname@example.org Discussion: https://email@example.com Backpatch-through: 9.3
doc: show how interval's 3 unit buckets behave using EXTRACT()
commit : 1d4b73cdddd43cbdeddb48b3cf7d96add7919a66 author : Bruce Momjian <firstname.lastname@example.org> date : Sat, 23 Jun 2018 23:32:41 -0400 committer: Bruce Momjian <email@example.com> date : Sat, 23 Jun 2018 23:32:41 -0400
This clarifies when justify_days() and justify_hours() are useful. Paragraph moved too. Reported-by: firstname.lastname@example.org Discussion: https://email@example.com Backpatch-through: 9.3
commit : 048abf83edc91086d76342e7e2c6bd7628298ccc author : Magnus Hagander <firstname.lastname@example.org> date : Wed, 20 Jun 2018 16:07:07 +0200 committer: Magnus Hagander <email@example.com> date : Wed, 20 Jun 2018 16:07:07 +0200
Reported using the website comment form
Use -Wno-format-truncation and -Wno-stringop-truncation, if available.
commit : ec5547e563a85cb84fc186dd96c41a86c59cc7fa author : Tom Lane <firstname.lastname@example.org> date : Sat, 16 Jun 2018 15:34:07 -0400 committer: Tom Lane <email@example.com> date : Sat, 16 Jun 2018 15:34:07 -0400
gcc 8 has started emitting some warnings that are largely useless for our purposes, particularly since they complain about code following the project-standard coding convention that path names are assumed to be shorter than MAXPGPATH. Even if we make the effort to remove that assumption in some future release, the changes wouldn't get back-patched. Hence, just suppress these warnings, on compilers that have these switches. Backpatch to all supported branches. Discussion: https://firstname.lastname@example.org
Avoid unnecessary use of strncpy in a couple of places in ecpg.
commit : 537d7f3e18757ac6ddab2e7cec80cc27bf303795 author : Tom Lane <email@example.com> date : Sat, 16 Jun 2018 14:58:11 -0400 committer: Tom Lane <firstname.lastname@example.org> date : Sat, 16 Jun 2018 14:58:11 -0400
Use of strncpy with a length limit based on the source, rather than the destination, is non-idiomatic and draws warnings from gcc 8. Replace with memcpy, which does exactly the same thing in these cases, but with less chance for confusion. Backpatch to all supported branches. Discussion: https://email@example.com
Use snprintf not sprintf in pg_waldump's timestamptz_to_str.
commit : 3243cbc085b8cd54cf12c323da3b5c8298ed5d69 author : Tom Lane <firstname.lastname@example.org> date : Sat, 16 Jun 2018 14:45:47 -0400 committer: Tom Lane <email@example.com> date : Sat, 16 Jun 2018 14:45:47 -0400
This could only cause an issue if strftime returned a ridiculously long timezone name, which seems unlikely; and it wouldn't qualify as a security problem even then, since pg_waldump (nee pg_xlogdump) is a debug tool not part of the server. But gcc 8 has started issuing warnings about it, so let's use snprintf and be safe. Backpatch to 9.3 where this code was added. Discussion: https://firstname.lastname@example.org
Fix bugs in vacuum of shared rels, by keeping their relcache entries current.
commit : 9b9b622b2a91c38b93bf415c4ecbffacb26ade5c author : Andres Freund <email@example.com> date : Tue, 12 Jun 2018 11:13:22 -0700 committer: Andres Freund <firstname.lastname@example.org> date : Tue, 12 Jun 2018 11:13:22 -0700
When vacuum processes a relation it uses the corresponding relcache entry's relfrozenxid / relminmxid as a cutoff for when to remove tuples etc. Unfortunately for nailed relations (i.e. critical system catalogs) bugs could frequently lead to the corresponding relcache entry being stale. This set of bugs could cause actual data corruption as vacuum would potentially not remove the correct row versions, potentially reviving them at a later point. After 699bf7d05c some corruptions in this vein were prevented, but the additional error checks could also trigger spuriously. Examples of such errors are: ERROR: found xmin ... from before relfrozenxid ... and ERROR: found multixact ... from before relminmxid ... To be caused by this bug the errors have to occur on system catalog tables. The two bugs are: 1) Invalidations for nailed relations were ignored, based on the theory that the relcache entry for such tables doesn't change. Which is largely true, except for fields like relfrozenxid etc. This means that changes to relations vacuumed in other sessions weren't picked up by already existing sessions. Luckily autovacuum doesn't have particularly longrunning sessions. 2) For shared *and* nailed relations, the shared relcache init file was never invalidated while running. That means that for such tables (e.g. pg_authid, pg_database) it's not just already existing sessions that are affected, but even new connections are as well. That explains why the reports usually were about pg_authid et. al. To fix 1), revalidate the rd_rel portion of a relcache entry when invalid. This implies a bit of extra complexity to deal with bootstrapping, but it's not too bad. The fix for 2) is simpler, simply always remove both the shared and local init files. Author: Andres Freund Reviewed-By: Alvaro Herrera Discussion: https://email@example.com https://postgr.es/m/CAMa1XUhKSJd98JW4o9StWPrfS=11bPgG+_GDMxe25TvUY4Sugg@mail.gmail.com https://postgr.es/m/CAKMFJucqbuoDRfxPDX39WhA3vJyxweRg_zDVXzncr6+5wOguWA@mail.gmail.com https://postgr.es/m/CAGewt-ujGpMLQ09gXcUFMZaZsGJC98VXHEFbF-tpPB0fB13K+A@mail.gmail.com Backpatch: 9.3-
Fix grammar in REVOKE documentation
commit : 50dfe3a44c65e8abf853d7bdc222002151c7046b author : Michael Paquier <firstname.lastname@example.org> date : Sun, 10 Jun 2018 22:44:17 +0900 committer: Michael Paquier <email@example.com> date : Sun, 10 Jun 2018 22:44:17 +0900
Reported-by: Erwin Brandstetter
Fix function code in error report
commit : 78d0b16f189a0ab153e309f6229466e875b5a502 author : Alvaro Herrera <firstname.lastname@example.org> date : Wed, 6 Jun 2018 14:46:53 -0400 committer: Alvaro Herrera <email@example.com> date : Wed, 6 Jun 2018 14:46:53 -0400
This bug causes a lseek() failure to be reported as a "could not open" failure in the error message, muddling bug reports. I introduced this copy-and-pasteo in commit 78e122010422. Noticed while reviewing code for bug report #15221, from lily liang. In version 10 the affected function is only used by multixact.c and commit_ts, and only in corner-case circumstances, neither of which are involved in the reported bug (a pg_subtrans failure.) Author: Álvaro Herrera
doc: mark 'replaceable' parameter for backup program listing
commit : a7d84ef5d783a6679d063ec908412c89fe95ed96 author : Bruce Momjian <firstname.lastname@example.org> date : Mon, 28 May 2018 14:19:45 -0400 committer: Bruce Momjian <email@example.com> date : Mon, 28 May 2018 14:19:45 -0400
Reported-by: Liudmila Mantrova Discussion: https://firstname.lastname@example.org Author: Liudmila Mantrova Backpatch-through: 9.3
doc: adjust DECLARE docs to mention FOR UPDATE behavior
commit : 7f5f74686dc3373626ce7e77d47b10c02cc48279 author : Bruce Momjian <email@example.com> date : Mon, 28 May 2018 13:16:02 -0400 committer: Bruce Momjian <firstname.lastname@example.org> date : Mon, 28 May 2018 13:16:02 -0400
Reported-by: Peter Eisentraut Discussion: https://email@example.com Author: Peter Eisentraut, Tom Lane, me Backpatch-through: 9.3
Fix misidentification of SQL statement type in plpgsql's exec_stmt_execsql.
commit : da757bf0ffb05ed3c18276bd1d4cdf1d2150de18 author : Tom Lane <firstname.lastname@example.org> date : Fri, 25 May 2018 14:31:07 -0400 committer: Tom Lane <email@example.com> date : Fri, 25 May 2018 14:31:07 -0400
To distinguish SQL statements that are INSERT/UPDATE/DELETE from other ones, exec_stmt_execsql looked at the post-rewrite form of the statement rather than the original. This is problematic because it did that only during first execution of the statement (in a session), but the correct answer could change later due to addition or removal of DO INSTEAD rules during the session. That could lead to an Assert failure, as reported by Tushar Ahuja and Robert Haas. In non-assert builds, there's a hazard that we would fail to enforce STRICT behavior when we'd be expected to. That would happen if an initially present DO INSTEAD, that replaced the original statement with one of a different type, were removed; after that the statement should act "normally", including strictness enforcement, but it didn't. (The converse case of enforcing strictness when we shouldn't doesn't seem to be a hazard, as addition of a DO INSTEAD that changes the statement type would always lead to acting as though the statement returned zero rows, so that the strictness error could not fire.) To fix, inspect the original form of the statement not the post-rewrite form, making it valid to assume the answer can't change intra-session. This should lead to the same answer in every case except when there is a DO INSTEAD that changes the statement type; we will now set mod_stmt=true anyway, while we would not have done so before. That breaks the Assert in the SPI_OK_REWRITTEN code path, which expected the latter behavior. It might be all right to assert mod_stmt rather than !mod_stmt there, but I'm not entirely convinced that that'd always hold, so just remove the assertion altogether. This has been broken for a long time, so back-patch to all supported branches. Discussion: https://postgr.es/m/CA+TgmoZUrRN4xvZe_BbBn_Xp0BDwuMEue-0OyF0fJpfvU2Yc7Q@mail.gmail.com
Remove incorrect statement about IPC configuration on OpenBSD
commit : 60242ebcfeae015462d5539d41c12b40fcad3045 author : Magnus Hagander <firstname.lastname@example.org> date : Fri, 25 May 2018 13:59:50 +0200 committer: Magnus Hagander <email@example.com> date : Fri, 25 May 2018 13:59:50 +0200
kern.ipc.shm_use_phys is not a sysctl on OpenBSD, and SEMMAP is not a kernel configuration option. These were probably copy pasteos from when the documentation had a single paragraph for *BSD. Author: Daniel Gustafsson <firstname.lastname@example.org>
Properly schema-qualify additional object types in getObjectDescription().
commit : cbb37b2e1fbe311c9fc7886ce0342fbc86e80840 author : Tom Lane <email@example.com> date : Thu, 24 May 2018 12:07:42 -0400 committer: Tom Lane <firstname.lastname@example.org> date : Thu, 24 May 2018 12:07:42 -0400
Collations, conversions, extended statistics objects (in >= v10), and all four types of text search objects have schema-qualified names. getObjectDescription() ignored that and would emit just the base name of the object, potentially producing wrong or at least highly misleading output. Fix it to add the schema name whenever the object is not "visible" in the current search path, as is the rule for other schema-qualifiable object types. Although in common situations the output won't change, this seems to me (tgl) to be a bug worthy of back-patching, hence do so. Kyotaro Horiguchi, per a complaint from me Discussion: https://email@example.com
Fix simple_prompt() to disable echo on Windows when stdin != terminal.
commit : 3466b0202cd61dd88c8033ca7cc9e1fa999c36d7 author : Tom Lane <firstname.lastname@example.org> date : Wed, 23 May 2018 19:04:34 -0400 committer: Tom Lane <email@example.com> date : Wed, 23 May 2018 19:04:34 -0400
If echo = false, simple_prompt() is supposed to prevent echoing the input (for password input). However, the Windows implementation applied the mode change to STD_INPUT_HANDLE. That would not have the desired effect if stdin isn't actually the terminal, for instance if the user is piping something into psql. Fix it to apply the mode change to the correct input file, so that passwords do not echo in such cases. In passing, shorten and de-uglify this code by using #elif rather than an #if nest and removing some duplicated code. Back-patch to all supported versions. To simplify that, also back-patch the portions of commit 9daec77e1 that got rid of an unnecessary malloc/free in the same area. Matthew Stickney (cosmetic changes by me) Discussion: https://firstname.lastname@example.org
Widen COPY FROM's current-line-number counter from 32 to 64 bits.
commit : d780283509044f322a82d447222b1d5f0a5e0e50 author : Tom Lane <email@example.com> date : Tue, 22 May 2018 13:32:52 -0400 committer: Tom Lane <firstname.lastname@example.org> date : Tue, 22 May 2018 13:32:52 -0400
Because the code for the HEADER option skips a line when this counter is zero, a very long COPY FROM WITH HEADER operation would drop a line every 2^32 lines. A lesser but still unfortunate problem is that errors would show a wrong input line number for errors occurring beyond the 2^31'st input line. While such large input streams seemed impractical when this code was first written, they're not any more. Widening the counter (and some associated variables) to uint64 should be enough to prevent problems for the foreseeable future. David Rowley Discussion: https://postgr.es/m/CAKJS1f88yh-6wwEfO6QLEEvH3BEugOq2QX1TOja0vCauoynmOQ@mail.gmail.com
Fix SQL:2008 FETCH FIRST syntax to allow parameters.
commit : 89b09db01b4323b3fb07384257373e02719f7573 author : Andrew Gierth <email@example.com> date : Mon, 21 May 2018 17:02:17 +0100 committer: Andrew Gierth <firstname.lastname@example.org> date : Mon, 21 May 2018 17:02:17 +0100
OFFSET <x> ROWS FETCH FIRST <y> ROWS ONLY syntax is supposed to accept <simple value specification>, which includes parameters as well as literals. When this syntax was added all those years ago, it was done inconsistently, with <x> and <y> being different subsets of the standard syntax. Rectify that by making <x> and <y> accept the same thing, and allowing either a (signed) numeric literal or a c_expr there, which allows for parameters, variables, and parenthesized arbitrary expressions. Per bug #15200 from Lukas Eder. Backpatch all the way, since this has been broken from the start. Discussion: https://email@example.com Discussion: http://firstname.lastname@example.org
printf("%lf") is not portable, so omit the "l".
commit : 0aa97b86f9021f2d4a5cd1aab04e0d33794d120b author : Tom Lane <email@example.com> date : Sun, 20 May 2018 11:40:55 -0400 committer: Tom Lane <firstname.lastname@example.org> date : Sun, 20 May 2018 11:40:55 -0400
The "l" (ell) width spec means something in the corresponding scanf usage, but not here. While modern POSIX says that applying "l" to "f" and other floating format specs is a no-op, SUSv2 says it's undefined. Buildfarm experience says that some old compilers emit warnings about it, and at least one old stdio implementation (mingw's "ANSI" option) actually produces wrong answers and/or crashes. Discussion: https://email@example.com Discussion: https://firstname.lastname@example.org
Support platforms where strtoll/strtoull are spelled __strtoll/__strtoull.
commit : 91f3bcc9e423b605046827bba549ac09fbb53db8 author : Tom Lane <email@example.com> date : Sat, 19 May 2018 14:22:19 -0400 committer: Tom Lane <firstname.lastname@example.org> date : Sat, 19 May 2018 14:22:19 -0400
Ancient HPUX, for one, does this. We hadn't noticed due to the lack of regression tests that required a working strtoll. (I was slightly tempted to remove the other historical spelling, strto[u]q, since it seems we have no buildfarm members testing that case. But I refrained.) Discussion: https://email@example.com
Arrange to supply declarations for strtoll/strtoull if needed.
commit : e9f475f991fb87afb39930a0aeee51fcfeeea042 author : Tom Lane <firstname.lastname@example.org> date : Fri, 18 May 2018 22:42:10 -0400 committer: Tom Lane <email@example.com> date : Fri, 18 May 2018 22:42:10 -0400
Buildfarm member dromedary is still unhappy about the recently-added ecpg "long long" tests. The reason turns out to be that it includes "-ansi" in its CFLAGS, and in their infinite wisdom Apple have decided to hide the declarations of strtoll/strtoull in C89-compliant builds. (I find it pretty curious that they hide those function declarations when you can nonetheless declare a "long long" variable, but anyway that is their behavior, both on dromedary's obsolete macOS version and the newest and shiniest.) As a result, gcc assumes these functions return "int", leading naturally to wrong results. (Looking at dromedary's past build results, it's evident that this problem also breaks pg_strtouint64() on 32-bit platforms; but we evidently have no regression tests that exercise that function with values above 32 bits.) To fix, supply declarations for these functions when the platform provides the functions but not the declarations, using the same type of mechanism as we use for some other similar cases. Discussion: https://firstname.lastname@example.org
Hot-fix ecpg regression test for missing ecpg_config.h inclusion.
commit : d73857d5719e10bc7ed8aabdf66daf03b1db7ddd author : Tom Lane <email@example.com> date : Fri, 18 May 2018 19:03:32 -0400 committer: Tom Lane <firstname.lastname@example.org> date : Fri, 18 May 2018 19:03:32 -0400
I don't think this is really the best long-term answer, and in particular it doesn't fix the pre-existing hazard in sqltypes.h. But for the moment let's just try to make the buildfarm green again. Discussion: https://email@example.com
Add some test coverage for ecpg's "long long" support.
commit : d9cbe9c9fce95807d08fb23f420b0a39a1e93483 author : Tom Lane <firstname.lastname@example.org> date : Fri, 18 May 2018 13:04:59 -0400 committer: Tom Lane <email@example.com> date : Fri, 18 May 2018 13:04:59 -0400
This will only actually exercise the "long long" code paths on platforms where "long" is 32 bits --- otherwise, the SQL bigint type maps to plain "long", and we will test that code path instead. But that's probably sufficient coverage, and anyway we weren't testing either code path before. Dang Minh Huong, tweaked a bit by me Discussion: https://firstname.lastname@example.org
Recognize that MSVC can support strtoll() and strtoull().
commit : 63d3e787f9544d0f2f8b39cf608e2c99a5896bde author : Tom Lane <email@example.com> date : Fri, 18 May 2018 12:52:28 -0400 committer: Tom Lane <firstname.lastname@example.org> date : Fri, 18 May 2018 12:52:28 -0400
This is needed for full support of "long long" variables in ecpg, but the previous patch for bug #15080 (commits 51057feaa et al) missed it. In MSVC versions where the functions don't exist under those names, we can nonetheless use _strtoi64() and _strtoui64(). Like the previous patch, back-patch all the way. Dang Minh Huong Discussion: https://email@example.com
Fix error message on short read of pg_control
commit : 048caa5560da33d63bbcbb2063c8ecd48994c99b author : Magnus Hagander <firstname.lastname@example.org> date : Fri, 18 May 2018 17:53:20 +0200 committer: Magnus Hagander <email@example.com> date : Fri, 18 May 2018 17:53:20 +0200
Instead of saying "error: success", indicate that we got a working read but it was too short.
Fix misprocessing of equivalence classes involving record_eq().
commit : bc711befd6ce24033175584f900e0cf43af81f5c author : Tom Lane <firstname.lastname@example.org> date : Wed, 16 May 2018 13:46:09 -0400 committer: Tom Lane <email@example.com> date : Wed, 16 May 2018 13:46:09 -0400
canonicalize_ec_expression() is supposed to agree with coerce_type() as to whether a RelabelType should be inserted to make a subexpression be valid input for the operators of a given opclass. However, it did the wrong thing with named-composite-type inputs to record_eq(): it put in a RelabelType to RECORDOID, which the parser doesn't. In some cases this was harmless because all code paths involving a particular equivalence class did the same thing, but in other cases this would result in failing to recognize a composite-type expression as being a member of an equivalence class that it actually is a member of. The most obvious bad effect was to fail to recognize that an index on a composite column could provide the sort order needed for a mergejoin on that column, as reported by Teodor Sigaev. I think there might be other, subtler, cases that result in misoptimization. It also seems possible that an unwanted RelabelType would sometimes get into an emitted plan --- but because record_eq and friends don't examine the declared type of their input expressions, that would not create any visible problems. To fix, just treat RECORDOID as if it were a polymorphic type, which in some sense it is. We might want to consider formalizing that a bit more someday, but for the moment this seems to be the only place where an IsPolymorphicType() test ought to include RECORDOID as well. This has been broken for a long time, so back-patch to all supported branches. Discussion: https://firstname.lastname@example.org
Update time zone data files to tzdata release 2018e.
commit : 3f36e4fc5b5b3e734f59aef9f31b918771dd0f2e author : Tom Lane <email@example.com> date : Wed, 9 May 2018 13:55:27 -0400 committer: Tom Lane <firstname.lastname@example.org> date : Wed, 9 May 2018 13:55:27 -0400
DST law changes in North Korea. Redefinition of "daylight savings" in Ireland, as well as for some past years in Namibia and Czechoslovakia. Additional historical corrections for Czechoslovakia. With this change, the IANA database models Irish timekeeping as following "standard time" in summer, and "daylight savings" in winter, so that the daylight savings offset is one hour behind standard time not one hour ahead. This does not change their UTC offset (+1:00 in summer, 0:00 in winter) nor their timezone abbreviations (IST in summer, GMT in winter), though now "IST" is more correctly read as "Irish Standard Time" not "Irish Summer Time". However, the "is_dst" column in the pg_timezone_names view will now be true in winter and false in summer for the Europe/Dublin zone. Similar changes were made for Namibia between 1994 and 2017, and for Czechoslovakia between 1946 and 1947. So far as I can find, no Postgres internal logic cares about which way tm_isdst is reported; in particular, since commit b2cbced9e we do not rely on it to decide how to interpret ambiguous timestamps during DST transitions. So I don't think this change will affect any Postgres behavior other than the timezone-view outputs. Discussion: https://email@example.com