Skip to main content

Browse the archive

https://github.com/postgres/postgres
07 April 2024, 13:56:23 UTC
sort by:
Revision Author Date Message Commit Date
b11e9bb Tom Lane 18 July 2016, 20:54:26 UTC Stamp 9.6beta3. 18 July 2016, 20:54:26 UTC
ade64d0 Tom Lane 18 July 2016, 20:52:06 UTC Doc: improve discussion of plpgsql's GET DIAGNOSTICS, other minor fixes. 9.4 added a second description of GET DIAGNOSTICS that was totally independent of the existing one, resulting in each description lying to the extent that it claimed the set of status items it described was complete. Fix that, and do some minor markup improvement. Also some other small fixes per bug #14258 from Dilian Palauzov. Discussion: <20160718181437.1414.40802@wrigleys.postgresql.org> 18 July 2016, 20:52:06 UTC
82bbfc7 Tom Lane 18 July 2016, 17:32:45 UTC Doc: fix table of BRIN operator strategy numbers. brin-extensibility-inclusion-table was confused in places about the difference between strategy 4 (RTOverRight) and strategy 5 (RTRight). Alexander Law 18 July 2016, 17:32:48 UTC
55d5735 Magnus Hagander 18 July 2016, 16:46:57 UTC Fix typos in comments and debug message Antonin Houska 18 July 2016, 16:46:57 UTC
7d67606 Peter Eisentraut 18 July 2016, 16:07:49 UTC Translation updates Source-Git-URL: git://git.postgresql.org/git/pgtranslation/messages.git Source-Git-Hash: 3d71988dffd3c0798a8864c55ca4b7833b48abb1 18 July 2016, 16:07:49 UTC
eca0f1d Andres Freund 18 July 2016, 09:01:13 UTC Clear all-frozen visibilitymap status when locking tuples. Since a892234 & fd31cd265 the visibilitymap's freeze bit is used to avoid vacuuming the whole relation in anti-wraparound vacuums. Doing so correctly relies on not adding xids to the heap without also unsetting the visibilitymap flag. Tuple locking related code has not done so. To allow selectively resetting all-frozen - to avoid pessimizing heap_lock_tuple - allow to selectively reset the all-frozen with visibilitymap_clear(). To avoid having to use visibilitymap_get_status (e.g. via VM_ALL_FROZEN) inside a critical section, have visibilitymap_clear() return whether any bits have been reset. There's a remaining issue (denoted by XXX): After the PageIsAllVisible() check in heap_lock_tuple() and heap_lock_updated_tuple_rec() the page status could theoretically change. Practically that currently seems impossible, because updaters will hold a page level pin already. Due to the next beta coming up, it seems better to get the required WAL magic bump done before resolving this issue. The added flags field fields to xl_heap_lock and xl_heap_lock_updated require bumping the WAL magic. Since there's already been a catversion bump since the last beta, that's not an issue. Reviewed-By: Robert Haas, Amit Kapila and Andres Freund Author: Masahiko Sawada, heavily revised by Andres Freund Discussion: CAEepm=3fWAbWryVW9swHyLTY4sXVf0xbLvXqOwUoDiNCx9mBjQ@mail.gmail.com Backpatch: - 18 July 2016, 09:01:13 UTC
6563208 Tom Lane 17 July 2016, 23:18:19 UTC Remove obsolete comment. Peter Geoghegan 17 July 2016, 23:18:19 UTC
18555b1 Tom Lane 17 July 2016, 22:42:31 UTC Establish conventions about global object names used in regression tests. To ensure that "make installcheck" can be used safely against an existing installation, we need to be careful about what global object names (database, role, and tablespace names) we use; otherwise we might accidentally clobber important objects. There's been a weak consensus that test databases should have names including "regression", and that test role names should start with "regress_", but we didn't have any particular rule about tablespace names; and neither of the other rules was followed with any consistency either. This commit moves us a long way towards having a hard-and-fast rule that regression test databases must have names including "regression", and that test role and tablespace names must start with "regress_". It's not completely there because I did not touch some test cases in rolenames.sql that test creation of special role names like "session_user". That will require some rethinking of exactly what we want to test, whereas the intent of this patch is just to hit all the cases in which the needed renamings are cosmetic. There is no enforcement mechanism in this patch either, but if we don't add one we can expect that the tests will soon be violating the convention again. Again, that's not such a cosmetic change and it will require discussion. (But I did use a quick-hack enforcement patch to find these cases.) Discussion: <16638.1468620817@sss.pgh.pa.us> 17 July 2016, 22:42:43 UTC
7482fc4 Peter Eisentraut 17 July 2016, 21:01:07 UTC doc: Supply XSLT template for superscript element in man pages The default is no decoration, which looks confusing, for example on the CREATE SEQUENCE man page. 17 July 2016, 21:01:07 UTC
f36ca9a Peter Eisentraut 17 July 2016, 13:15:37 UTC Use correct symbol for minimum int64 value The old code used SEQ_MINVALUE to get the smallest int64 value. This was done as a convenience to avoid having to deal with INT64_IS_BUSTED, but that is obsolete now. Also, it is incorrect because the smallest int64 value is actually SEQ_MINVALUE-1. Fix by using PG_INT64_MIN. 17 July 2016, 13:15:37 UTC
47f5bb9 Stephen Frost 17 July 2016, 13:04:46 UTC Correctly dump database and tablespace ACLs Dump out the appropriate GRANT/REVOKE commands for databases and tablespaces from pg_dumpall to replicate what the current state is. This was broken during the changes to buildACLCommands for 9.6+ servers for pg_init_privs. 17 July 2016, 13:04:46 UTC
fe03f28 Tom Lane 16 July 2016, 22:39:47 UTC Update 9.6 release notes through today. 16 July 2016, 22:39:47 UTC
606ccc5 Tom Lane 16 July 2016, 20:25:43 UTC Improve test case exercising the sorting path for hash index build. On second thought, we should probably do at least a minimal check that the constructed index is valid, since the big problem with the most recent breakage was not whether the sorting was correct but that the index had incorrect hash codes placed in it. 16 July 2016, 20:25:43 UTC
9563d5b Tom Lane 16 July 2016, 19:30:15 UTC Add regression test case exercising the sorting path for hash index build. We've broken this code path at least twice in the past, so it's prudent to have a test case that covers it. To allow exercising the code path without creating a very large (and slow to run) test case, redefine the sort threshold to be bounded by maintenance_work_mem as well as the number of available buffers. While at it, fix an ancient oversight that when building a temp index, the number of available buffers is not NBuffers but NLocBuffer. Also, if assertions are enabled, apply a direct test that the sort actually does return the tuples in the expected order. Peter Geoghegan Patch: <CAM3SWZTBAo4hjbBd780+MrOKiKp_TMo1N3A0Rw9_im8gbD7fQA@mail.gmail.com> 16 July 2016, 19:30:15 UTC
2781489 Tom Lane 16 July 2016, 18:42:37 UTC Fix crash in close_ps() for NaN input coordinates. The Assert() here seems unreasonably optimistic. Andreas Seltenreich found that it could fail with NaNs in the input geometries, and it seems likely to me that it might fail in corner cases due to roundoff error, even for ordinary input values. As a band-aid, make the function return SQL NULL instead of crashing. Report: <87d1md1xji.fsf@credativ.de> 16 July 2016, 18:42:37 UTC
745513c Tom Lane 16 July 2016, 18:12:44 UTC Clarify usage of clientcert authentication option. For some reason this option wasn't discussed at all in client-auth.sgml. Document it there, and be more explicit about its relationship to the "cert" authentication method. Per gripe from Srikanth Venkatesh. I failed to resist the temptation to do some minor wordsmithing in the same area, too. Discussion: <20160713110357.1410.30407@wrigleys.postgresql.org> 16 July 2016, 18:12:44 UTC
99dd8b0 Tom Lane 16 July 2016, 16:49:14 UTC Advance PG_CONTROL_VERSION. This should have been done in commit 73c986adde5d73a5 which added several new fields to pg_control, and again in commit 5028f22f6eb05798 which changed the CRC algorithm, but it wasn't. It's far too late to fix it in the 9.5 branch, but let's do so in 9.6, so that if a 9.6 postmaster is started against a 9.4-era pg_control it will complain about a versioning problem rather than a CRC failure. We already forced initdb/pg_upgrade for beta3, so there's no downside to doing this now. Discussion: <7615.1468598094@sss.pgh.pa.us> 16 July 2016, 16:49:14 UTC
bfa2ab5 Andres Freund 16 July 2016, 00:49:48 UTC Fix torn-page, unlogged xid and further risks from heap_update(). When heap_update needs to look for a page for the new tuple version, because the current one doesn't have sufficient free space, or when columns have to be processed by the tuple toaster, it has to release the lock on the old page during that. Otherwise there'd be lock ordering and lock nesting issues. To avoid concurrent sessions from trying to update / delete / lock the tuple while the page's content lock is released, the tuple's xmax is set to the current session's xid. That unfortunately was done without any WAL logging, thereby violating the rule that no XIDs may appear on disk, without an according WAL record. If the database were to crash / fail over when the page level lock is released, and some activity lead to the page being written out to disk, the xid could end up being reused; potentially leading to the row becoming invisible. There might be additional risks by not having t_ctid point at the tuple itself, without having set the appropriate lock infomask fields. To fix, compute the appropriate xmax/infomask combination for locking the tuple, and perform WAL logging using the existing XLOG_HEAP_LOCK record. That allows the fix to be backpatched. This issue has existed for a long time. There appears to have been partial attempts at preventing dangers, but these never have fully been implemented, and were removed a long time ago, in 11919160 (cf. HEAP_XMAX_UNLOGGED). In master / 9.6, there's an additional issue, namely that the visibilitymap's freeze bit isn't reset at that point yet. Since that's a new issue, introduced only in a892234f830, that'll be fixed in a separate commit. Author: Masahiko Sawada and Andres Freund Reported-By: Different aspects by Thomas Munro, Noah Misch, and others Discussion: CAEepm=3fWAbWryVW9swHyLTY4sXVf0xbLvXqOwUoDiNCx9mBjQ@mail.gmail.com Backpatch: 9.1/all supported versions 16 July 2016, 00:49:48 UTC
a4d357b Andres Freund 15 July 2016, 21:37:06 UTC Make HEAP_LOCK/HEAP2_LOCK_UPDATED replay reset HEAP_XMAX_INVALID. 0ac5ad5 started to compress infomask bits in WAL records. Unfortunately the replay routines for XLOG_HEAP_LOCK/XLOG_HEAP2_LOCK_UPDATED forgot to reset the HEAP_XMAX_INVALID (and some other) hint bits. Luckily that's not problematic in the majority of cases, because after a crash/on a standby row locks aren't meaningful. Unfortunately that does not hold true in the presence of prepared transactions. This means that after a crash, or after promotion, row level locks held by a prepared, but not yet committed, prepared transaction might not be enforced. Discussion: 20160715192319.ubfuzim4zv3rqnxv@alap3.anarazel.de Backpatch: 9.3, the oldest branch on which 0ac5ad5 is present. 15 July 2016, 21:45:37 UTC
45639a0 Tom Lane 15 July 2016, 21:22:56 UTC Avoid invalidating all foreign-join cached plans when user mappings change. We must not push down a foreign join when the foreign tables involved should be accessed under different user mappings. Previously we tried to enforce that rule literally during planning, but that meant that the resulting plans were dependent on the current contents of the pg_user_mapping catalog, and we had to blow away all cached plans containing any remote join when anything at all changed in pg_user_mapping. This could have been improved somewhat, but the fact that a syscache inval callback has very limited info about what changed made it hard to do better within that design. Instead, let's change the planner to not consider user mappings per se, but to allow a foreign join if both RTEs have the same checkAsUser value. If they do, then they necessarily will use the same user mapping at runtime, and we don't need to know specifically which one that is. Post-plan-time changes in pg_user_mapping no longer require any plan invalidation. This rule does give up some optimization ability, to wit where two foreign table references come from views with different owners or one's from a view and one's directly in the query, but nonetheless the same user mapping would have applied. We'll sacrifice the first case, but to not regress more than we have to in the second case, allow a foreign join involving both zero and nonzero checkAsUser values if the nonzero one is the same as the prevailing effective userID. In that case, mark the plan as only runnable by that userID. The plancache code already had a notion of plans being userID-specific, in order to support RLS. It was a little confused though, in particular lacking clarity of thought as to whether it was the rewritten query or just the finished plan that's dependent on the userID. Rearrange that code so that it's clearer what depends on which, and so that the same logic applies to both RLS-injected role dependency and foreign-join-injected role dependency. Note that this patch doesn't remove the other issue mentioned in the original complaint, which is that while we'll reliably stop using a foreign join if it's disallowed in a new context, we might fail to start using a foreign join if it's now allowed, but we previously created a generic cached plan that didn't use one. It was agreed that the chance of winning that way was not high enough to justify the much larger number of plan invalidations that would have to occur if we tried to cause it to happen. In passing, clean up randomly-varying spelling of EXPLAIN commands in postgres_fdw.sql, and fix a COSTS ON example that had been allowed to leak into the committed tests. This reverts most of commits fbe5a3fb7 and 5d4171d1c, which were the previous attempt at ensuring we wouldn't push down foreign joins that span permissions contexts. Etsuro Fujita and Tom Lane Discussion: <d49c1e5b-f059-20f4-c132-e9752ee0113e@lab.ntt.co.jp> 15 July 2016, 21:23:02 UTC
533e9c6 Alvaro Herrera 15 July 2016, 18:17:20 UTC Avoid serializability errors when locking a tuple with a committed update When key-share locking a tuple that has been not-key-updated, and the update is a committed transaction, in some cases we raised serializability errors: ERROR: could not serialize access due to concurrent update Because the key-share doesn't conflict with the update, the error is unnecessary and inconsistent with the case that the update hasn't committed yet. This causes problems for some usage patterns, even if it can be claimed that it's sufficient to retry the aborted transaction: given a steady stream of updating transactions and a long locking transaction, the long transaction can be starved indefinitely despite multiple retries. To fix, we recognize that HeapTupleSatisfiesUpdate can return HeapTupleUpdated when an updating transaction has committed, and that we need to deal with that case exactly as if it were a non-committed update: verify whether the two operations conflict, and if not, carry on normally. If they do conflict, however, there is a difference: in the HeapTupleBeingUpdated case we can just sleep until the concurrent transaction is gone, while in the HeapTupleUpdated case this is not possible and we must raise an error instead. Per trouble report from Olivier Dony. In addition to a couple of test cases that verify the changed behavior, I added a test case to verify the behavior that remains unchanged, namely that errors are raised when a update that modifies the key is used. That must still generate serializability errors. One pre-existing test case changes behavior; per discussion, the new behavior is actually the desired one. Discussion: https://www.postgresql.org/message-id/560AA479.4080807@odoo.com https://www.postgresql.org/message-id/20151014164844.3019.25750@wrigleys.postgresql.org Backpatch to 9.3, where the problem appeared. 15 July 2016, 18:17:20 UTC
00f304c Teodor Sigaev 15 July 2016, 17:01:41 UTC Fix parsing NOT sequence in tsquery Digging around bug #14245 I found that commit 6734a1cacd44f5b731933cbc93182b135b167d0c missed that NOT operation is right associative in opposite to all other. This miss is resposible for tsquery parser fail on sequence of NOT operations 15 July 2016, 17:01:41 UTC
19d2901 Teodor Sigaev 15 July 2016, 16:22:18 UTC Fix nested NOT operation cleanup in tsquery. During normalization of tsquery tree it tries to simplify nested NOT operations but there it's obvioulsy missed that subsequent node could be a leaf node (value node) Bug #14245: Segfault on weird to_tsquery Reported by David Kellum. 15 July 2016, 16:22:18 UTC
ce150e7 Tom Lane 15 July 2016, 14:58:39 UTC Improve documentation about search_path for SECURITY DEFINER functions. Clarify that the reason for recommending that pg_temp be put last is to prevent temporary tables from capturing unqualified table names. Per discussion with Albe Laurenz. Discussion: <A737B7A37273E048B164557ADEF4A58B5386C6E1@ntex2010i.host.magwien.gv.at> 15 July 2016, 14:58:39 UTC
63cfdb8 Peter Eisentraut 15 July 2016, 02:48:26 UTC Adjust spellings of forms of "cancel" 15 July 2016, 02:48:26 UTC
3aed52a Peter Eisentraut 15 July 2016, 02:28:58 UTC doc: Fix typos From: Alexander Law <exclusion@gmail.com> 15 July 2016, 02:28:58 UTC
1acf757 Tom Lane 14 July 2016, 22:45:59 UTC Fix GiST index build for NaN values in geometric types. GiST index build could go into an infinite loop when presented with boxes (or points, circles or polygons) containing NaN component values. This happened essentially because the code assumed that x == x is true for any "double" value x; but it's not true for NaNs. The looping behavior was not the only problem though: we also attempted to sort the items using simple double comparisons. Since NaNs violate the trichotomy law, qsort could (in principle at least) get arbitrarily confused and mess up the sorting of ordinary values as well as NaNs. And we based splitting choices on box size calculations that could produce NaNs, again resulting in undesirable behavior. To fix, replace all comparisons of doubles in this logic with float8_cmp_internal, which is NaN-aware and is careful to sort NaNs consistently, higher than any non-NaN. Also rearrange the box size calculation to not produce NaNs; instead it should produce an infinity for a box with NaN on one side and not-NaN on the other. I don't by any means claim that this solves all problems with NaNs in geometric values, but it should at least make GiST index insertion work reliably with such data. It's likely that the index search side of things still needs some work, and probably regular geometric operations too. But with this patch we're laying down a convention for how such cases ought to behave. Per bug #14238 from Guang-Dih Lei. Back-patch to 9.2; the code used before commit 7f3bd86843e5aad8 is quite different and doesn't lock up on my simple test case, nor on the submitter's dataset. Report: <20160708151747.1426.60150@wrigleys.postgresql.org> Discussion: <28685.1468246504@sss.pgh.pa.us> 14 July 2016, 22:45:59 UTC
00e0b67 Magnus Hagander 14 July 2016, 13:39:01 UTC Remove reference to range mode in pg_xlogdump error pg_xlogdump doesn't have any other mode, so it's just confusing to include this in the error message as it indicates there might be another mode. 14 July 2016, 13:39:01 UTC
56a9974 Tom Lane 13 July 2016, 19:36:25 UTC Minor test adjustment. Dept of second thoughts: given the RESET SESSION AUTHORIZATION that was just added by commit cec550139, we don't need the reconnection that used to be here. Might as well buy back a few microseconds. 13 July 2016, 19:36:25 UTC
cec5501 Tom Lane 13 July 2016, 19:23:56 UTC Add a regression test case to improve code coverage for tuplesort. Test the external-sort code path in CLUSTER for two different scenarios: multiple-pass external sorting, and the best case for replacement selection, where only one run is produced, so that no merge is required. This test would have caught the bug fixed in commit 1b0fc8507, at least when run with valgrind enabled. In passing, add a short-circuit test in plan_cluster_use_sort() to make dead certain that it selects sorting when enable_indexscan is off. As things stand, that would happen anyway, but it seems like good future proofing for this test. Peter Geoghegan Discussion: <CAM3SWZSgxehDkDMq1FdiW2A0Dxc79wH0hz1x-TnGy=1BXEL+nw@mail.gmail.com> 13 July 2016, 19:23:56 UTC
91c0eb5 Tom Lane 13 July 2016, 15:17:15 UTC Fix obsolete header-file reference in pg_buffercache docs. Commit 2d0019049 moved enum ForkNumber from relfilenode.h into relpath.h, but missed updating this documentation reference. Alexander Law 13 July 2016, 15:17:15 UTC
42ec6c2 Stephen Frost 13 July 2016, 13:17:35 UTC Add missing hyphen Pointed out by Alexander Law 13 July 2016, 13:17:35 UTC
5d40500 Peter Eisentraut 12 July 2016, 22:37:34 UTC Add serial comma and quoting to message 12 July 2016, 22:37:34 UTC
b9fc9f7 Peter Eisentraut 12 July 2016, 22:10:16 UTC Put some things in a better order in psql help 12 July 2016, 22:11:45 UTC
baebab3 Tom Lane 12 July 2016, 22:06:50 UTC Allow IMPORT FOREIGN SCHEMA within pl/pgsql. Since IMPORT FOREIGN SCHEMA has an INTO clause, pl/pgsql needs to be aware of that and avoid capturing the INTO as an INTO-variables clause. This isn't hard, though it's annoying to have to make IMPORT a plpgsql keyword just for this. (Fortunately, we have the infrastructure now to make it an unreserved keyword, so at least this shouldn't break any existing pl/pgsql code.) Per report from Merlin Moncure. Back-patch to 9.5 where IMPORT FOREIGN SCHEMA was introduced. Report: <CAHyXU0wpHf2bbtKGL1gtUEFATCY86r=VKxfcACVcTMQ70mCyig@mail.gmail.com> 12 July 2016, 22:07:03 UTC
d3fbd59 Peter Eisentraut 12 July 2016, 17:30:48 UTC doc: Fix typo From: Alexander Law <exclusion@gmail.com> 12 July 2016, 17:30:48 UTC
4d04299 Tom Lane 11 July 2016, 22:14:29 UTC Print a given subplan only once in EXPLAIN. We have, for a very long time, allowed the same subplan (same member of the PlannedStmt.subplans list) to be referenced by more than one SubPlan node; this avoids problems for cases such as subplans within an IndexScan's indxqual and indxqualorig fields. However, EXPLAIN had not gotten the memo and would print each reference as though it were an independent identical subplan. To fix, track plan_ids of subplans we've printed and don't print the same plan_id twice. Per report from Pavel Stehule. BTW: the particular case of IndexScan didn't cause visible duplication in a plain EXPLAIN, only EXPLAIN ANALYZE, because in the former case we short-circuit executor startup before the indxqual field is processed by ExecInitExpr. That seems like it could easily lead to other EXPLAIN problems in future, but it's not clear how to avoid it without breaking the "EXPLAIN a plan using hypothetical indexes" use-case. For now I've left that issue alone. Although this is a longstanding bug, it's purely cosmetic (no great harm is done by the repeat printout) and we haven't had field complaints before. So I'm hesitant to back-patch it, especially since there is some small risk of ABI problems due to the need to add a new field to ExplainState. In passing, rearrange order of fields in ExplainState to be less random, and update some obsolete comments about when/where to initialize them. Report: <CAFj8pRAimq+NK-menjt+3J4-LFoodDD8Or6=Lc_stcFD+eD4DA@mail.gmail.com> 11 July 2016, 22:14:29 UTC
a670c24 Tom Lane 11 July 2016, 16:35:03 UTC Improve output of psql's \df+ command. Add display of proparallel (parallel-safety) when the server is >= 9.6, and display of proacl (access privileges) for all server versions. Minor tweak of column ordering to keep related columns together. Michael Paquier Discussion: <CAB7nPqTR3Vu3xKOZOYqSm-+bSZV0kqgeGAXD6w5GLbkbfd5Q6w@mail.gmail.com> 11 July 2016, 16:35:08 UTC
740bf39 Peter Eisentraut 11 July 2016, 16:10:10 UTC doc: Update URL for PL/PHP 11 July 2016, 16:10:10 UTC
ae7d78c Magnus Hagander 11 July 2016, 11:53:17 UTC Add missing newline in error message 11 July 2016, 11:53:17 UTC
87d84d6 Magnus Hagander 11 July 2016, 10:02:31 UTC Fix start WAL filename for concurrent backups from standby On a standby, ThisTimelineID is always 0, so we would generate a filename in timeline 0 even for other timelines. Instead, use starttli which we have retreived from the controlfile. Report by: Francesco Canovai in bug #14230 Author: Marco Nenciarini Reviewed by: Michael Paquier and Amit Kapila 11 July 2016, 10:02:31 UTC
96112ee Tom Lane 10 July 2016, 16:44:20 UTC Revert "Add some temporary code to record stack usage at server process exit." This reverts commit 88cf37d2a86d5b66380003d7c3384530e3f91e40 as well as follow-on commits ea9c4a16d5ad88a1d28d43ef458e3209b53eb106 and c57562725d219c4249b82f4a4fb5aaeee3ae0d53. We've learned about as much as we can from the buildfarm. 10 July 2016, 16:44:20 UTC
30b2731 Tom Lane 09 July 2016, 20:47:38 UTC Fix TAP tests and MSVC scripts for pathnames with spaces. Change assorted places in our Perl code that did things like system("prog $path/file"); to do it more like system('prog', "$path/file"); which is safe against spaces and other special characters in the path variable. The latter was already the prevailing style, but a few bits of code hadn't gotten this memo. Back-patch to 9.4 as relevant. Michael Paquier, Kyotaro Horiguchi Discussion: <20160704.160213.111134711.horiguchi.kyotaro@lab.ntt.co.jp> 09 July 2016, 20:47:38 UTC
c575627 Tom Lane 09 July 2016, 19:00:22 UTC Improve recording of IA64 stack data. Examination of the results from anole and gharial suggests that we're only managing to track the size of one of the two stacks of IA64 machines. Some googling gave the answer: on HPUX11, the register stack is reported as a page type I don't see in pstat.h on my HPUX10 box. Let's try testing for that. 09 July 2016, 19:00:22 UTC
ea9c4a1 Tom Lane 08 July 2016, 20:38:22 UTC Add more temporary code to record stack usage at server process exit. After a look at preliminary results from commit 88cf37d2a86d5b66, I realized it'd be a good idea to spew out the maximum depth measurement seen by check_stack_depth. So add some quick-n-dirty code to do that. Like the previous commit, this will be reverted once we've gathered a set of buildfarm runs with it. 08 July 2016, 20:38:22 UTC
769159f Tom Lane 08 July 2016, 17:23:09 UTC Docs: minor improvements for documentation about plpgsql triggers. Fabien Coelho, some further wordsmithing by me 08 July 2016, 17:23:09 UTC
8ba4ccd Tom Lane 08 July 2016, 16:46:04 UTC Docs: improve examples about not repeating table name in UPDATE ... SET. Alexander Law 08 July 2016, 16:46:04 UTC
262c1b2 Tom Lane 08 July 2016, 16:40:51 UTC Docs: typo fix. Etsuro Fujita 08 July 2016, 16:40:51 UTC
88cf37d Tom Lane 08 July 2016, 16:01:08 UTC Add some temporary code to record stack usage at server process exit. This patch is meant to gather information from the buildfarm members, and will be reverted in a day or so. The idea is to try to find out the high-water stack consumption while running the regression tests, particularly on IA64 which is suspected to use much more stack than other architectures. On machines with pmap, we can use that; but the IA64 farm members are running HPUX, so also include some bespoke code for HPUX. (I've tested the latter on HPUX 10/HPPA; not entirely sure it will work on HPUX 11/IA64, but we'll soon find out.) Discussion: <CAM-w4HMwwcwaVvYcAH0_FGtG5GeXdYVRfvG81pXnSJWHnCfosQ@mail.gmail.com> 08 July 2016, 16:01:08 UTC
e8bde9e Stephen Frost 08 July 2016, 13:26:53 UTC Typo fix, buils -> builds Pointed out by Alexander Law. 08 July 2016, 13:26:53 UTC
51dc308 Magnus Hagander 08 July 2016, 07:06:45 UTC Fix missing parenthesis in docs Author: Alexander Law 08 July 2016, 07:06:45 UTC
3edcdbc Robert Haas 07 July 2016, 20:13:37 UTC Fix typo in comment. Amit Langote 07 July 2016, 20:13:37 UTC
1b0fc85 Robert Haas 07 July 2016, 17:47:16 UTC Properly adjust pointers when tuples are moved during CLUSTER. Otherwise, when we abandon incremental memory accounting and use batch allocation for the final merge pass, we might crash. This has been broken since 0011c0091e886b874e485a46ff2c94222ffbf550. Peter Geoghegan, tested by Noah Misch 07 July 2016, 17:47:16 UTC
b22934d Robert Haas 07 July 2016, 17:46:51 UTC Fix a prototype which is inconsistent with the function definition. Peter Geoghegan 07 July 2016, 17:46:51 UTC
d1f822e Robert Haas 07 July 2016, 15:18:51 UTC Clarify resource utilization of parallel query. temp_file_limit is a per-process limit, not a per-session limit across all cooperating parallel processes; change wording accordingly, per a suggestion from Tom Lane. Also, document under max_parallel_workers_per_gather the fact that each process involved in a parallel query may use as many resources as a separate session. Caveat emptor. Per a complaint from Peter Geoghegan. 07 July 2016, 15:35:08 UTC
62c8421 Tom Lane 07 July 2016, 15:28:17 UTC Reduce stack space consumption in tzload(). While syncing our timezone code with IANA's updates in commit 1c1a7cbd6, I'd chosen not to adopt the code they conditionally compile under #ifdef ALL_STATE. The main thing that that drives is that the space for gmtime and localtime timezone definitions isn't statically allocated, but is malloc'd on first use. I reasoned we didn't need that logic: we don't have localtime() at all, and we always initialize TimeZone to GMT so we always need that one. But there is one other thing ALL_STATE does, which is to make tzload() malloc its transient workspace instead of just declaring it as a local variable. It turns out that that local variable occupies 78K. Even worse is that, at least for common US timezone settings, there's a recursive call to parse the "posixrules" zone name, making peak stack consumption to select a time zone upwards of 150K. That's an uncomfortably large fraction of our STACK_DEPTH_SLOP safety margin, and could result in outright crashes if we try to reduce STACK_DEPTH_SLOP as has been discussed recently. Furthermore, this means that the postmaster's peak stack consumption is several times that of a backend running typical queries (since, except on Windows, backends inherit the timezone GUC values and don't ever run this code themselves unless you do SET TIMEZONE). That's completely backwards from a safety perspective. Hence, adopt the ALL_STATE rather than non-ALL_STATE variant of tzload(), while not changing the other code aspects that symbol controls. The risk of an ENOMEM error from malloc() seems less than that of a SIGSEGV from stack overrun. This should probably get back-patched along with 1c1a7cbd6 and followon fixes, whenever we decide we have enough confidence in the updates to do that. 07 July 2016, 15:28:17 UTC
60d5076 Fujii Masao 07 July 2016, 03:59:39 UTC Rename pg_stat_wal_receiver.conn_info to conninfo. Per discussion on pgsql-hackers, conninfo is better as the column name because it's more commonly used in PostgreSQL. Catalog version bumped due to the change of pg_proc. Author: Michael Paquier 07 July 2016, 03:59:39 UTC
397bf6e Peter Eisentraut 07 July 2016, 01:18:03 UTC Fix typos 07 July 2016, 01:18:03 UTC
9b7bb10 Peter Eisentraut 07 July 2016, 01:09:26 UTC doc: Fix option order in man pages and fix typos 07 July 2016, 01:09:26 UTC
1109164 Fujii Masao 06 July 2016, 09:59:17 UTC Fix typo in comment. Author: Masahiko Sawada 06 July 2016, 09:59:17 UTC
9c810a2 Tom Lane 04 July 2016, 20:09:11 UTC Fix failure to handle conflicts in non-arbiter exclusion constraints. ExecInsertIndexTuples treated an exclusion constraint as subject to noDupErr processing even when it was not listed in arbiterIndexes, and would therefore not error out for a conflict in such a constraint, instead returning it as an arbiter-index failure. That led to an infinite loop in ExecInsert, since ExecCheckIndexConstraints ignored the index as-intended and therefore didn't throw the expected error. To fix, make the exclusion constraint code path use the same condition as the index_insert call does to decide whether no-error-for-duplicates behavior is appropriate. While at it, refactor a little bit to avoid unnecessary list_member_oid calls. (That surely wouldn't save anything worth noticing, but I find the code a bit clearer this way.) Per bug report from Heikki Rauhala. Back-patch to 9.5 where ON CONFLICT was introduced. Report: <4C976D6B-76B4-434C-8052-D009F7B7AEDA@reaktor.fi> 04 July 2016, 20:09:11 UTC
29a2195 Tom Lane 03 July 2016, 22:43:43 UTC Typo fix. 03 July 2016, 22:43:43 UTC
110a6db Tom Lane 03 July 2016, 22:24:49 UTC Allow RTE_SUBQUERY rels to be considered parallel-safe. There isn't really any reason not to; the original comments here were partly confused about subplans versus subquery-in-FROM, and partly dependent on restrictions that no longer apply now that subqueries return Paths not Plans. Depending on what's inside the subquery, it might fail to produce any parallel_safe Paths, but that's fine. Tom Lane and Robert Haas 03 July 2016, 22:24:49 UTC
4ea9948 Tom Lane 03 July 2016, 21:57:28 UTC Fix up parallel-safety marking for appendrels. The previous coding assumed that the value derived by set_rel_consider_parallel() for an appendrel parent would be accurate for all the appendrel's children; but this is not so, for example because one child might scan a temp table. Instead, apply set_rel_consider_parallel() to each child rel as well as the parent, and then take the AND of the results as controlling parallel safety for the appendrel as a whole. (We might someday be able to deal more intelligently than this with cases in which some of the childrels are parallel-safe and others not, but that's for later.) Robert Haas and Tom Lane 03 July 2016, 21:57:28 UTC
2c6e647 Tom Lane 03 July 2016, 20:55:27 UTC Allow treating TABLESAMPLE scans as parallel-safe. This was the intention all along, but an extraneous "return;" in set_rel_consider_parallel() caused sampled rels to never be marked consider_parallel. Since we don't have any partial tablesample path/plan type yet, there's no possibility of parallelizing the sample scan itself; but this fix allows such a scan to appear below a parallel join, for example. 03 July 2016, 20:55:27 UTC
0e495c5 Tom Lane 03 July 2016, 19:35:29 UTC Set correct cost data in Gather node added by force_parallel_mode. We were just leaving the cost fields zeroes, which produces obviously bogus output with force_parallel_mode = on. With force_parallel_mode = regress, the zeroes are hidden, but I wonder if they wouldn't still confuse add-on code such as auto_explain. 03 July 2016, 19:35:29 UTC
c89d507 Tom Lane 03 July 2016, 18:53:37 UTC Round rowcount estimate for a partial path to an integer. I'd been wondering why I was sometimes seeing fractional rowcount estimates in parallel-query situations, and this seems to be the reason. (You won't see the fractional parts in EXPLAIN, because it prints rowcounts with %.0f, but they are apparent in the debugger.) A fractional rowcount is not any saner for a partial path than any other kind of path, and it's equally likely to break cost estimation for higher paths, so apply clamp_row_est() like we do in other places. 03 July 2016, 18:53:46 UTC
3a4a33a Peter Eisentraut 03 July 2016, 02:53:14 UTC PL/Python: Report argument parsing errors using exceptions Instead of calling PLy_elog() for reporting Python argument parsing errors, generate appropriate exceptions. This matches the existing plpy functions and is more consistent with the behavior of the Python argument parsing routines. 03 July 2016, 02:53:14 UTC
420c166 Tom Lane 02 July 2016, 17:23:02 UTC Fix failure to mark all aggregates with appropriate transtype. In commit 915b703e1 I gave get_agg_clause_costs() the responsibility of marking Aggref nodes with the appropriate aggtranstype. I failed to notice that where it was being called from, it might see only a subset of the Aggref nodes that were in the original targetlist. Specifically, if there are duplicate aggregate calls in the tlist, either make_sort_input_target or make_window_input_target might put just a single instance into the grouping_target, and then only that instance would get marked. Fix by moving the call back into grouping_planner(), before we start building assorted PathTargets from the query tlist. Per report from Stefan Huehner. Report: <20160702131056.GD3165@huehner.biz> 02 July 2016, 17:23:12 UTC
b54f7a9 Bruce Momjian 02 July 2016, 15:22:36 UTC doc: mention dependency on collation libraries Document that index storage is dependent on the operating system's collation library ordering, and any change in that ordering can create invalid indexes. Discussion: 20160617154311.GB19359@momjian.us Backpatch-through: 9.1 02 July 2016, 15:22:36 UTC
7b67a0a Tom Lane 02 July 2016, 00:05:55 UTC Fix some interrelated planner issues with initPlans and Param munging. In commit 68fa28f77 I tried to teach SS_finalize_plan() to cope with initPlans attached anywhere in the plan tree, by dint of moving its handling of those into the recursion in finalize_plan(). It turns out that that doesn't really work: if a lower-level plan node emits an initPlan output parameter in its targetlist, it's legitimate for upper levels to reference those Params --- and at the point where this code runs, those references look just like the Param itself, so finalize_plan() quite properly rejects them as being in the wrong place. We could lobotomize the checks enough to allow that, probably, but then it's not clear that we'd have any meaningful check for misplaced Params at all. What seems better, at least in the near term, is to tweak standard_planner() a bit so that initPlans are never placed anywhere but the topmost plan node for a query level, restoring the behavior that occurred pre-9.6. Possibly we can do better if this code is ever merged into setrefs.c: then it would be possible to check a Param's placement only when we'd failed to replace it with a Var referencing a child plan node's targetlist. BTW, I'm now suspicious that finalize_plan is doing the wrong thing by returning the node's allParam rather than extParam to be incorporated in the parent node's set of used parameters. However, it makes no difference given that initPlans only appear at top level, so I'll leave that alone for now. Another thing that emerged from this is that standard_planner() needs to check for initPlans before deciding that it's safe to stick a Gather node on top in force_parallel_mode mode. We previously guarded against that by deciding the plan wasn't wholePlanParallelSafe if any subplans had been found, but after commit 5ce5e4a12 it's necessary to have this substitute test, because path parallel_safe markings don't account for initPlans. (Normally, we'd have decided the paths weren't safe anyway due to appearances of SubPlan nodes, Params, or CTE scans somewhere in the tree --- but it's possible for those all to be optimized away while initPlans still remain.) Per fuzz testing by Andreas Seltenreich. Report: <874m89rw7x.fsf@credativ.de> 02 July 2016, 00:06:05 UTC
48bfeb2 Andres Freund 01 July 2016, 21:27:53 UTC Improve WritebackContextInit() comment and prototype argument names. Author: Masahiko Sawada Discussion: CAD21AoBD=Of1OzL90Xx4Q-3j=-2q7=S87cs75HfutE=eCday2w@mail.gmail.com 01 July 2016, 21:29:03 UTC
548af97 Tom Lane 01 July 2016, 19:08:55 UTC Provide and use a makefile target to build all generated headers. As of 9.6, pg_regress doesn't build unless storage/lwlocknames.h has been created; but there was nothing forcing that to happen if you just went into src/test/regress/ and built there. We previously had a similar complaint about plpython. To fix in a way that won't break next time we invent a generated header, make src/backend/Makefile expose a phony target for updating all the include files it builds, and invoke that before building pg_regress or plpython. In principle, maybe we ought to invoke that everywhere; but it would add a lot of usually-useless make cycles, so let's just do it in the places where people have complained. I made a couple of cosmetic adjustments in src/backend/Makefile as well, to deal with the generated headers in consistent orders. Michael Paquier and Tom Lane Report: <31398.1467036827@sss.pgh.pa.us> Report: <20150916200959.GB32090@msg.df7cb.de> 01 July 2016, 19:09:02 UTC
1bdae16 Alvaro Herrera 01 July 2016, 17:53:46 UTC walreceiver: tweak pg_stat_wal_receiver behavior There are two problems in the original coding: one is that if one walreceiver process exits, the ready_to_display flag remains set in shared memory, exposing the conninfo of the next walreceiver before obfuscating. Fix by having WalRcvDie reset the flag. Second, the sleep-and-retry behavior that waited until walreceiver had set ready_to_display wasn't liked; the preference is to have it return no data instead, so let's do that. Bugs in 9ed551e0a reported by Fujii Masao and Michël Paquier. Author: Michaël Paquier 01 July 2016, 17:53:46 UTC
9e70398 Tom Lane 01 July 2016, 17:12:34 UTC Rethink the GetForeignUpperPaths API (again). In the previous design, the GetForeignUpperPaths FDW callback hook was called before we got around to labeling upper relations with the proper consider_parallel flag; this meant that any upper paths created by an FDW would be marked not-parallel-safe. While that's probably just as well right now, we aren't going to want it to be true forever. Hence, abandon the idea that FDWs should be allowed to inject upper paths before the core code has gotten around to creating the relevant upper relation. (Well, actually they still can, but it's on their own heads how well it works.) Instead, adopt the same API already designed for create_upper_paths_hook: we call GetForeignUpperPaths after each upperrel has been created and populated with the paths the core planner knows how to make. 01 July 2016, 17:12:34 UTC
5ce5e4a Robert Haas 01 July 2016, 15:43:19 UTC Set consider_parallel correctly for upper planner rels. Commit 3fc6e2d7f5b652b417fa6937c34de2438d60fa9f introduced new "upper" RelOptInfo structures but didn't set consider_parallel for them correctly, a point I completely missed when reviewing it. Later, commit e06a38965b3bcdaa881e7e06892d4d8ab6c2c980 made the situation worse by doing it incorrectly for the grouping relation. Try to straighten all of that out. Along the way, get rid of the annoying wholePlanParallelSafe flag, which was only necessarily because of the fact that upper planning stages didn't use paths at the time that code was written. The most important immediate impact of these changes is that force_parallel_mode will provide useful test coverage in quite a few more scenarios than it did previously, but it's also necessary preparation for fixing some problems related to subqueries. Patch by me, reviewed by Tom Lane. 01 July 2016, 15:52:56 UTC
0daeba0 Tom Lane 01 July 2016, 15:40:22 UTC Be more paranoid in ruleutils.c's get_variable(). We were merely Assert'ing that the Var matched the RTE it's supposedly from. But if the user passes incorrect information to pg_get_expr(), the RTE might in fact not match; this led either to Assert failures or core dumps, as reported by Chris Hanks in bug #14220. To fix, just convert the Asserts to test-and-elog. Adjust an existing test-and-elog elsewhere in the same function to be consistent in wording. (If we really felt these were user-facing errors, we might promote them to ereport's; but I can't convince myself that they're worth translating.) Back-patch to 9.3; the problematic code doesn't exist before that, and a quick check says that 9.2 doesn't crash on such cases. Michael Paquier and Thomas Munro Report: <20160629224349.1407.32667@wrigleys.postgresql.org> 01 July 2016, 15:40:33 UTC
86437dd Robert Haas 01 July 2016, 15:29:25 UTC postgres_fdw: Fix cache lookup failure while creating error context. This is fallout from join pushdown; get_relid_attribute_name can't handle an attribute number of 0, indicating a whole-row reference, and shouldn't be called in that case. Etsuro Fujita, reviewed by Ashutosh Bapat 01 July 2016, 15:29:25 UTC
5f3499b Robert Haas 01 July 2016, 14:13:06 UTC postgres_fdw: Remove schema-qualification from cast to text. As pointed out by Ashutosh Bapat, the header comments for this file say that schema-qualification is needed for all and only those types outside pg_catalog. pg_catalog.text is not outside pg_catalog. 01 July 2016, 14:14:42 UTC
4f9f495 Robert Haas 01 July 2016, 12:51:58 UTC Fix crash bug in RestoreSnapshot. If serialized_snapshot->subxcnt > 0 and serialized_snapshot->xcnt == 0, the old coding would do the wrong thing and crash. This can happen on standby servers. Report by Andreas Seltenreich. Patch by Thomas Munro, reviewed by Amit Kapila and tested by Andreas Seltenreich. 01 July 2016, 13:04:11 UTC
10c0558 Robert Haas 30 June 2016, 22:35:32 UTC Fix several mistakes around parallel workers and client_encoding. Previously, workers sent data to the leader using the client encoding. That mostly worked, but the leader the converted the data back to the server encoding. Since not all encoding conversions are reversible, that could provoke failures. Fix by using the database encoding for all communication between worker and leader. Also, while temporary changes to GUC settings, as from the SET clause of a function, are in general OK for parallel query, changing client_encoding this way inside of a parallel worker is not OK. Previously, that would have confused the leader; with these changes, it would not confuse the leader, but it wouldn't do anything either. So refuse such changes in parallel workers. Also, the previous code naively assumed that when it received a NotifyResonse from the worker, it could pass that directly back to the user. But now that worker-to-leader communication always uses the database encoding, that's clearly no longer correct - though, actually, the old way was always broken for V2 clients. So disassemble and reconstitute the message instead. Issues reported by Peter Eisentraut. Patch by me, reviewed by Peter Eisentraut. 30 June 2016, 22:35:32 UTC
f8c5855 Tom Lane 30 June 2016, 16:37:02 UTC Fix typo in ReorderBufferIterTXNInit(). This looks like it would cause changes from subtransactions to be missed by the iterator being constructed, if those changes had been spilled to disk previously. This implies that large subtransactions might be lost (in whole or in part) by logical replication. Found and fixed by Petru-Florin Mihancea, per bug #14208. Report: <20160622144830.5791.22512@wrigleys.postgresql.org> 30 June 2016, 16:37:02 UTC
3154e16 Tom Lane 29 June 2016, 23:07:19 UTC Dodge compiler bug in Visual Studio 2013. VS2013 apparently has a problem with taking the address of a formal parameter in some cases. We do that elsewhere without trouble, but in this case the address is being passed to a subroutine that will probably get inlined, so maybe the combination of those things is what tickles the bug. Anyway, introducing an extra copy of the parameter value is enough to work around it. Per trouble report from Umair Shahid. Report: <CAM184AcjqKYZSdQqBHDrnENXHhW=mXbUC46QYPJ=nAh0gUHCGA@mail.gmail.com> 29 June 2016, 23:07:19 UTC
8ebb69f Tom Lane 29 June 2016, 22:51:20 UTC Fix some infelicities in EXPLAIN output for parallel query plans. In non-text output formats, parallelized aggregates were reporting "Partial" or "Finalize" as a field named "Operation", which might be all right in the absence of any context --- but other plan node types use that field to report SQL-visible semantics, such as Select/Insert/Update/Delete. So that naming choice didn't seem good to me. I changed it to "Partial Mode". Also, the field did not appear at all for a non-parallelized Agg plan node, which is contrary to expectation in non-text formats. We're notionally producing objects that conform to a schema, so the set of fields for a given node type and EXPLAIN mode should be well-defined. I set it up to fill in "Simple" in such cases. Other fields that were added for parallel query, namely "Parallel Aware" and Gather's "Single Copy", had not gotten the word on that point either. Make them appear always in non-text output. Also, the latter two fields were nominally producing boolean output, but were getting it wrong, because bool values shouldn't be quoted in JSON or YAML. Somehow we'd not needed an ExplainPropertyBool formatting subroutine before 9.6; but now we do, so invent it. Discussion: <16002.1466972724@sss.pgh.pa.us> 29 June 2016, 22:51:20 UTC
0584df3 Tom Lane 29 June 2016, 21:13:29 UTC Update rules.out to match commit 9ed551e0a. Per buildfarm. 29 June 2016, 21:13:29 UTC
9ed551e Alvaro Herrera 29 June 2016, 20:57:17 UTC Add conninfo to pg_stat_wal_receiver Commit b1a9bad9e744 introduced a stats view to provide insight into the running WAL receiver, but neglected to include the connection string in it, as reported by Michaël Paquier. This commit fixes that omission. (Any security-sensitive information is not disclosed). While at it, close the mild security hole that we were exposing the password in the connection string in shared memory. This isn't user-accessible, but it still looks like a good idea to avoid having the cleartext password in memory. Author: Michaël Paquier, Álvaro Herrera Review by: Vik Fearing Discussion: https://www.postgresql.org/message-id/CAB7nPqStg4M561obo7ryZ5G+fUydG4v1Ajs1xZT1ujtu+woRag@mail.gmail.com 29 June 2016, 20:57:17 UTC
b32e635 Tom Lane 29 June 2016, 20:02:08 UTC Fix match_foreign_keys_to_quals for FKs linking to unused rtable entries. Since get_relation_foreign_keys doesn't try to determine whether RTEs are actually part of the query semantics, it might make FK info records linking to RTEs that won't have a RelOptInfo at all. Cope with that. Per bug #14219 from Andrew Gierth. Report: <20160629183338.1397.43514@wrigleys.postgresql.org> 29 June 2016, 20:02:08 UTC
4242a71 Tom Lane 29 June 2016, 19:00:25 UTC Adjust text search documentation for recent commits. Fix some now-obsolete statements that were overlooked in commits 6734a1cac, 3dbbd0f02, 028350f61. Document the behavior of <0>. Also do a little bit of rearranging and copy-editing for clarity. 29 June 2016, 19:00:33 UTC
8dee039 Robert Haas 29 June 2016, 17:12:50 UTC Fix obsolete comment. Commit 3bd261ca18c67eafe18088e58fab511e3b965418 should have updated this, but didn't. Extracted from a larger patch by Piotr Stefaniak. 29 June 2016, 17:12:50 UTC
73e6bea Teodor Sigaev 29 June 2016, 14:59:36 UTC Document precedence of FTS operators in tsquery Oleg Bartunov 29 June 2016, 14:59:36 UTC
8a395e0 Bruce Momjian 28 June 2016, 20:16:06 UTC doc: add link for list-of-scalars mention Reported-by: Manlio Perillo Bug: 14016 Discussion: 20160311163928.6674.94707@wrigleys.postgresql.org Reviewed-by: David G. Johnston 28 June 2016, 20:16:06 UTC
46eafc8 Bruce Momjian 28 June 2016, 20:09:04 UTC doc: update effective_io_concurrency for SSDs SSDs are no longer exotic, so recommend a default in the hundreds for them. 28 June 2016, 20:09:15 UTC
b78364d Alvaro Herrera 28 June 2016, 20:01:13 UTC Remove unused arguments in two GiST subroutines These arguments became unused in commit 2c03216d8311. Noticed while skimming code for unrelated development. This is cosmetic, so no backpatch. 28 June 2016, 20:01:13 UTC
8e1ad1b Bruce Momjian 28 June 2016, 20:00:40 UTC doc: remove GIN vs. GiST performance mention This is a followup to commit 6d8b2aa83af70e20323caf23961667dc4c149276. 28 June 2016, 20:00:40 UTC
69769a3 Bruce Momjian 28 June 2016, 18:21:43 UTC doc: in binary mode mention, say "encoding conversion" Used to say "character set conversion" Reported-by: Tatsuo Ishii Discussion: 20160618.210417.343199294611427151.t-ishii@sraoss.co.jp 28 June 2016, 18:21:43 UTC
675684f Bruce Momjian 28 June 2016, 17:49:37 UTC doc: remove mention of UT1 in representing time UT1 was incorrectly specified as our time representation. (UT1 is astronomical time.) We are not actually UTC either because we ignore leap seconds. Reported-by: Thomas Munro Discussion: CAEepm=3-TW9PLwGZhqjSSiEQ9UzJEKE-HELQDzRE0QUSCp8dgw@mail.gmail.com 28 June 2016, 17:49:37 UTC
c12f02f Tom Lane 28 June 2016, 14:43:11 UTC Don't apply sortgroupref labels to a tlist that might not match. If we need to use a gating Result node for pseudoconstant quals, create_scan_plan() intentionally suppresses use_physical_tlist's checks on whether there are matches for sortgroupref labels, on the grounds that we don't need matches because we can label the Result's projection output properly. However, it then called apply_pathtarget_labeling_to_tlist anyway. This oversight was harmless when written, but in commit aeb9ae645 I made that function throw an error if there was no match. Thus, the combination of a table scan, pseudoconstant quals, and a non-simple-Var sortgroupref column threw the dreaded "ORDER/GROUP BY expression not found in targetlist" error. To fix, just skip applying the labeling in this case. Per report from Rushabh Lathia. Report: <CAGPqQf2iLB8t6t-XrL-zR233DFTXxEsfVZ4WSqaYfLupEoDxXA@mail.gmail.com> 28 June 2016, 14:43:11 UTC
957616d Robert Haas 27 June 2016, 21:54:28 UTC Fix mistakes in pg_visibility documentation. Michael Paquier 27 June 2016, 21:55:03 UTC
874fe3a Tom Lane 27 June 2016, 19:57:21 UTC Fix CREATE MATVIEW/CREATE TABLE AS ... WITH NO DATA to not plan the query. Previously, these commands always planned the given query and went through executor startup before deciding not to actually run the query if WITH NO DATA is specified. This behavior is problematic for pg_dump because it may cause errors to be raised that we would rather not see before a REFRESH MATERIALIZED VIEW command is issued. See for example bug #13907 from Marian Krucina. This change is not sufficient to fix that particular bug, because we also need to tweak pg_dump to issue the REFRESH later, but it's a necessary step on the way. A user-visible side effect of doing things this way is that the returned command tag for WITH NO DATA cases will now be "CREATE MATERIALIZED VIEW" or "CREATE TABLE AS", not "SELECT 0". We could preserve the old behavior but it would take more code, and arguably that was just an implementation artifact not intended behavior anyhow. In 9.5 and HEAD, also get rid of the static variable CreateAsReladdr, which was trouble waiting to happen; there is not any prohibition on nested CREATE commands. Back-patch to 9.3 where CREATE MATERIALIZED VIEW was introduced. Michael Paquier and Tom Lane Report: <20160202161407.2778.24659@wrigleys.postgresql.org> 27 June 2016, 19:57:50 UTC
6734a1c Teodor Sigaev 27 June 2016, 17:55:24 UTC Change predecence of phrase operator. <-> operator now have higher predecence than & (AND) operator. This change was motivated by unexpected difference of similar queries: 'a & b <-> c'::tsquery and 'b <-> c & a'. Before first query means (a & b) <-> c and second one - '(b <-> c) & a', now phrase operator evaluates first. Per suggestion from Tom Lane 32260.1465402409@sss.pgh.pa.us 27 June 2016, 17:55:24 UTC
back to top