- 07 2月, 2016 5 次提交
-
-
由 Robert Haas 提交于
For locking purposes, we now regard heavyweight locks as mutually non-conflicting between cooperating parallel processes. There are some possible pitfalls to this approach that are not to be taken lightly, but it works OK for now and can be changed later if we find a better approach. Without this, it's very easy for parallel queries to silently self-deadlock if the user backend holds strong relation locks. Robert Haas, with help from Amit Kapila. Thanks to Noah Misch and Andres Freund for extensive discussion of possible issues with this approach.
-
由 Tom Lane 提交于
It seems that sprintf(), at least in glibc's version, is unreasonably slow compared to hand-rolled code for printing integers. Replacing most uses of sprintf() in the datetime.c output functions with special-purpose code turns out to give more than a 2X speedup in COPY of a table with a single timestamp column; which is pretty impressive considering all the other logic in that code path. David Rowley and Andres Freund, reviewed by Peter Geoghegan and myself
-
由 Tom Lane 提交于
Commit 30d7ae3c introduced an HJDEBUG stanza that probably didn't compile at the time, and definitely doesn't compile now, because it refers to a nonexistent variable. It doesn't seem terribly useful anyway, so just get rid of it. While I'm fooling with it, use %z modifier instead of the obsolete hack of casting size_t to unsigned long, and include the HashJoinTable's address in each printout so that it's possible to distinguish the activities of multiple hashjoins occurring in one query. Noted while trying to use HJDEBUG to investigate bug #13908. Back-patch to 9.5, because code that doesn't compile is certainly not very helpful.
-
由 Tom Lane 提交于
Per buildfarm member pademelon.
-
- 06 2月, 2016 3 次提交
-
-
由 Noah Misch 提交于
Reviewed by Tom Lane and Robert Haas.
-
由 Noah Misch 提交于
Future PL/Java versions will close CVE-2016-0766 by making these GUCs PGC_SUSET. This PostgreSQL change independently mitigates that PL/Java vulnerability, helping sites that update PostgreSQL more frequently than PL/Java. Back-patch to 9.1 (all supported versions).
-
由 Tom Lane 提交于
As usual, the release notes for other branches will be made by cutting these down, but put them up for community review first.
-
- 05 2月, 2016 13 次提交
-
-
由 Tom Lane 提交于
DST law changes in Cayman Islands, Metlakatla, Trans-Baikal Territory (Zabaykalsky Krai). Historical corrections for Pakistan.
-
由 Robert Haas 提交于
Michael Paquier
-
由 Robert Haas 提交于
Commit a104a017 has this check because I added it to the submitted patch before commit, but that was entirely wrongheaded, as explained to me by Ashutosh Bapat, who also wrote this patch.
-
由 Robert Haas 提交于
Peter Geoghegan
-
由 Robert Haas 提交于
Amit Kapila
-
由 Tom Lane 提交于
An example use-case is "CHECK(num_nonnulls(a,b,c) = 1)" to assert that exactly one of a,b,c isn't NULL. The functions are variadic, so they can also be pressed into service to count the number of null or nonnull elements in an array. Marko Tiikkaja, reviewed by Pavel Stehule
-
由 Robert Haas 提交于
In preparation for upcoming commits.
-
由 Robert Haas 提交于
deparseReturningList ended up adding up RETURNING NULL to the code, but code elsewhere saw an empty list of attributes and concluded that it should not expect tuples from the remote side. Etsuro Fujita and Robert Haas, reviewed by Thom Brown
-
由 Robert Haas 提交于
Failure to do this can cause AFTER ROW triggers or RETURNING expressions that reference this field to misbehave. Etsuro Fujita, reviewed by Thom Brown
-
由 Peter Eisentraut 提交于
-
由 Robert Haas 提交于
GetExistingLocalJoinPath() is useful for handling EvalPlanQual rechecks properly, and GetUserMappingById() is needed to make sure you're using the right credentials. Shigeru Hanada, Etsuro Fujita, Ashutosh Bapat, Robert Haas
-
由 Robert Haas 提交于
The previous RequestAddinLWLocks() method had several disadvantages. First, the locks would be in the main tranche; we've recently decided that it's useful for LWLocks used for separate purposes to have separate tranche IDs. Second, there wasn't any correlation between what code called RequestAddinLWLocks() and what code called LWLockAssign(); when multiple modules are in use, it could become quite difficult to troubleshoot problems where LWLockAssign() ran out of locks. To fix, create a concept of named LWLock tranches which can be used either by extension or by core code. Amit Kapila and Robert Haas
-
由 Tom Lane 提交于
Since there currently is only one possible parenthesized option, namely VERBOSE, it's a bit pointless to show it with "{ } [, ... ]". The curly braces are useless and therefore confusing, as seen in a recent question from Karsten Hilbert. Remove the extra decoration for the time being; we can put it back when and if REINDEX grows some more options.
-
- 04 2月, 2016 7 次提交
-
-
由 Tom Lane 提交于
If a view is split into CREATE TABLE + CREATE RULE to break a circular dependency, then any triggers on the view must be dumped/reloaded after the CREATE RULE; else the backend may reject the CREATE TRIGGER because it's the wrong type of trigger for a plain table. This works all right in plain dump/restore because of pg_dump's sorting heuristic that places triggers after rules. However, when using parallel restore, the ordering must be enforced by a dependency --- and we didn't have one. Fixing this is a mere matter of adding an addObjectDependency() call, except that we need to be able to find all the triggers belonging to the view relation, and there was no easy way to do that. Add fields to pg_dump's TableInfo struct to remember where the associated TriggerInfo struct(s) are. Per bug report from Dennis Kögel. The failure can be exhibited at least as far back as 9.1, so back-patch to all supported branches.
-
由 Robert Haas 提交于
Have varlena.c expose an interface that allows the char(n), bytea, and bpchar types to piggyback on a now-generalized SortSupport for text. This pushes a little more knowledge of the bpchar/char(n) type into varlena.c than might be preferred, but that seems like the approach that creates least friction. Also speed things up for index builds that use text_pattern_ops or varchar_pattern_ops. This patch does quite a bit of renaming, but it seems likely to be worth it, so as to avoid future confusion about the fact that this code is now more generally used than the old names might have suggested. Peter Geoghegan, reviewed by Álvaro Herrera and Andreas Karlsson, with small tweaks by me.
-
由 Tom Lane 提交于
These were never documented anywhere user-visible. Tut tut.
-
由 Robert Haas 提交于
This patch doesn't put the new infrastructure to use anywhere, and indeed it's not clear how it could ever be used for something like postgres_fdw which has to send an SQL query and wait for a reply, but there might be FDWs or custom scan providers that are CPU-bound, so let's give them a way to join club parallel. KaiGai Kohei, reviewed by me.
-
由 Peter Eisentraut 提交于
Commit 7d17e683 introduced an external link.
-
由 Tom Lane 提交于
Commit e09996ff removed some ad-hoc code in hstore_to_json_loose that determined whether an hstore value string looked like a number, in favor of calling the JSON parser's is-it-a-number code. However, it neglected the fact that the exact same code appeared in hstore_to_jsonb_loose. This is not a bug, exactly, because the requirements on the two functions are not the same: hstore_to_json_loose must accept only syntactically legal JSON numbers as numbers, or it will produce invalid JSON output, as per bug #12070 which spawned the prior commit. But hstore_to_jsonb_loose could accept anything that numeric_in will eat, other than Inf and NaN. Nonetheless it seems surprising and arbitrary that the two functions don't use the same rules for what is a number versus what is a string; especially since they did use the same rules before the aforesaid commit. For one thing, that means that doing hstore_to_json_loose and then casting to jsonb can produce results different from doing just hstore_to_jsonb_loose. Hence, change hstore_to_jsonb_loose's logic to match hstore_to_json_loose, ie, hstore values are treated as numbers when they match the JSON syntax for numbers. No back-patch, since this is more in the nature of a definitional change than a bug fix.
-
由 Robert Haas 提交于
Remove duplicate assignment. This part by Ashutosh Bapat. Remove now-obsolete comment. This part by me, although the pending join pushdown patch does something similar, and for the same reason: there's no reason to keep two lists of the things in the fdw_private structure that have to be kept in sync with each other.
-
- 03 2月, 2016 9 次提交
-
-
由 Robert Haas 提交于
You can't really do anything useful with this in the form it currently exists; among other problems, there's no way to reread whatever information might be produced when the path is output. Work is underway to replace this with a more useful and more general system of extensible nodes, but let's start by getting rid of this bit. Extracted from a larger patch by KaiGai Kohei.
-
由 Robert Haas 提交于
The default fetch size of 100 rows might not be right in every environment, so allow users to configure it. Corey Huinker, reviewed by Kyotaro Horiguchi, Andres Freund, and me.
-
由 Tom Lane 提交于
Commit e09996ff was one brick shy of a load: it didn't insist that the detected JSON number be the whole of the supplied string. This allowed inputs such as "2016-01-01" to be misdetected as valid JSON numbers. Per bug #13906 from Dmitry Ryabov. In passing, be more wary of zero-length input (I'm not sure this can happen given current callers, but better safe than sorry), and do some minor cosmetic cleanup.
-
由 Peter Eisentraut 提交于
Insert sd_notify() calls at server start and stop for integration with systemd. This allows the use of systemd service units of type "notify", which greatly simplifies the systemd configuration. Reviewed-by: NPavel Stěhule <pavel.stehule@gmail.com>
-
由 Peter Eisentraut 提交于
Previously, the first error seen would be that postgresql.conf does not exist. But for the case where the whole directory does not exist, give an error message about that, together with a hint for how to create one.
-
由 Alvaro Herrera 提交于
create_foreignscan_plan needs to know whether any system columns are requested from a relation (this flag is needed by ForeignNext during execution). However, for join relations this is a pointless test, because it's not possible to request system columns from them, so remove the check. Author: Etsuro Fujita Discussion: http://www.postgresql.org/message-id/56AA0FC5.9000207@lab.ntt.co.jp Reviewed-by: David Rowley, Robert Haas
-
由 Tom Lane 提交于
Apparently at least one committer hasn't gotten the word that these do not need to be maintained by hand, since initdb will create them automatically. Noted while fixing bug #13905. No catversion bump since the post-initdb state is exactly the same either way. I don't see a need for back-patch, either.
-
由 Tom Lane 提交于
All the other jsonb function descriptions refer to the arguments as being "jsonb", but these two said "json". Make it consistent. Per bug #13905 from Petru Florin Mihancea. No catversion bump --- we can't force one in the back branches, and this isn't very critical anyway.
-
- 02 2月, 2016 3 次提交
-
-
由 Magnus Hagander 提交于
-
由 Teodor Sigaev 提交于
KNN GiST with recheck flag should return to executor the same type as ordering operator, GiST detects this type by looking to return type of function which implements ordering operator. But occasionally detecting code works after replacing ordering operator function to distance support function. Distance support function always returns float8, so, detecting code get float8 instead of actual return type of ordering operator. Built-in opclasses don't have ordering operator which doesn't return non-float8 value, so, tests are impossible here, at least now. Backpatch to 9.5 where lozzy KNN was introduced. Author: Alexander Korotkov Report by: Artur Zakirov
-
由 Robert Haas 提交于
This makes the values more stable, which seems like a good thing for anybody who needs to look at at them. Alexander Korotkov and Amit Kapila
-