- 17 9月, 2013 2 次提交
-
-
由 Alvaro Herrera 提交于
This has been unused since commit 8563ccae. Noted by Antonin Houska
-
由 Alvaro Herrera 提交于
It seems to make more sense to use "cutoff multixact" terminology throughout the backend code; "freeze" is associated with replacing of an Xid with FrozenTransactionId, which is not what we do for MultiXactIds. Andres Freund Some adjustments by Álvaro Herrera
-
- 16 9月, 2013 1 次提交
-
-
由 Heikki Linnakangas 提交于
Bernd Helmle
-
- 15 9月, 2013 1 次提交
-
-
由 Peter Eisentraut 提交于
-
- 12 9月, 2013 2 次提交
-
-
由 Noah Misch 提交于
Once the administrator has called for an immediate shutdown or a backend crash has triggered a reinitialization, no mere SIGINT or SIGTERM should change that course. Such derailment remains possible when the signal arrives before quickdie() blocks signals. That being a narrow race affecting most PostgreSQL signal handlers in some way, leave it for another patch. Back-patch this to all supported versions.
-
由 Kevin Grittner 提交于
Comments and the tests make clear that the intent is to test with and without an index, but there was no index.
-
- 11 9月, 2013 6 次提交
-
-
由 Bruce Momjian 提交于
Albe Laurenz
-
由 Bruce Momjian 提交于
Josh Kupershmidt
-
由 Bruce Momjian 提交于
Gurjeet Singh
-
由 Bruce Momjian 提交于
Previously a trailing space was required for \copy ... stdin: copy foo from stdin ; Etsuro Fujita
-
由 Bruce Momjian 提交于
"No rows" previously only honored the tuples-only option. Per report from Eli Mesika
-
由 Fujii Masao 提交于
The prototype for inval_twophase_postcommit wasn't removed when it's definition was removed in efc16ea5 / the initial HS commit. Andres Freund
-
- 10 9月, 2013 2 次提交
-
-
由 Peter Eisentraut 提交于
Before, it would only show schemas that the current user owns. Per discussion, the new behavior is more useful and consistent for PostgreSQL.
-
由 Robert Haas 提交于
This allows a 32-bit field to represent an *optional* command ID without a separate flag bit. Andres Freund
-
- 08 9月, 2013 2 次提交
-
-
由 Michael Meskes 提交于
Found by Coverity.
-
由 Michael Meskes 提交于
-
- 07 9月, 2013 2 次提交
-
-
由 Bruce Momjian 提交于
Previously a one-dimensional empty array was returned, but its text representation matched a zero-dimensional array, and there is no way to dump/reload a one-dimensional empty array. BACKWARD INCOMPATIBILITY Per report from elein
-
由 Noah Misch 提交于
Doing so was helpful for some Valgrind usage and distracting for other usage. One can achieve the same effect by changing log_statement and pointing both PostgreSQL and Valgrind logging to stderr. Per gripe from Andres Freund.
-
- 06 9月, 2013 2 次提交
-
-
由 Kevin Grittner 提交于
Commit 95ef6a34 removed the ability to create rules on an individual column as of 7.3, but left some residual code which has since been useless. This cleans up that dead code without any change in behavior other than dropping the useless column from the catalog.
-
由 Heikki Linnakangas 提交于
If the hash table backing a catalog cache becomes too full (fillfactor > 2), enlarge it. A new buckets array, double the size of the old, is allocated, and all entries in the old hash are moved to the right bucket in the new hash. This has two benefits. First, cache lookups don't get so expensive when there are lots of entries in a cache, like if you access hundreds of thousands of tables. Second, we can make the (initial) sizes of the caches much smaller, which saves memory. This patch dials down the initial sizes of the catcaches. The new sizes are chosen so that a backend that only runs a few basic queries still won't need to enlarge any of them.
-
- 05 9月, 2013 5 次提交
-
-
由 Jeff Davis 提交于
This reverts commit 269e7808 and commit 5b571bb8. Unfortunately, the initial patch had insufficient performance testing, and resulted in a regression. Per report by Thom Brown.
-
由 Jeff Davis 提交于
Make the examples self-contained to avoid confusion. Per bug report 8367 from KOIZUMI Satoru.
-
由 Bruce Momjian 提交于
Previous text was "No description available". Tianyin Xu
-
由 Bruce Momjian 提交于
Backpatch to 9.3. Per suggestion from Gavan Schneider
-
由 Heikki Linnakangas 提交于
Performance testing shows that if the insertpos_lck spinlock and the fields that it protects are on the same cache line with other variables that are frequently accessed, the false sharing can hurt performance a lot. Keep them apart by adding some padding.
-
- 04 9月, 2013 8 次提交
-
-
由 Robert Haas 提交于
Andres Freund
-
由 Tom Lane 提交于
This GUC context value was once only used by ALTER DATABASE SET and ALTER USER SET. That's not true anymore, though, so rewrite the comments to be a bit more general. Patch in HEAD only, since this is just an internal documentation issue.
-
由 Tom Lane 提交于
The previous coding attempted to activate all the GUC settings specified in SET clauses, so that the function validator could operate in the GUC environment expected by the function body. However, this is problematic when restoring a dump, since the SET clauses might refer to database objects that don't exist yet. We already have the parameter check_function_bodies that's meant to prevent forward references in function definitions from breaking dumps, so let's change CREATE FUNCTION to not install the SET values if check_function_bodies is off. Authors of function validators were already advised not to make any "context sensitive" checks when check_function_bodies is off, if indeed they're checking anything at all in that mode. But extend the documentation to point out the GUC issue in particular. (Note that we still check the SET clauses to some extent; the behavior with !check_function_bodies is now approximately equivalent to what ALTER DATABASE/ROLE have been doing for awhile with context-dependent GUCs.) This problem can be demonstrated in all active branches, so back-patch all the way.
-
由 Tom Lane 提交于
There's no inherent reason why an aggregate function can't be variadic (even VARIADIC ANY) if its transition function can handle the case. Indeed, this patch to add the feature touches none of the planner or executor, and little of the parser; the main missing stuff was DDL and pg_dump support. It is true that variadic aggregates can create the same sort of ambiguity about parameters versus ORDER BY keys that was complained of when we (briefly) had both one- and two-argument forms of string_agg(). However, the policy formed in response to that discussion only said that we'd not create any built-in aggregates with varying numbers of arguments, not that we shouldn't allow users to do it. So the logical extension of that is we can allow users to make variadic aggregates as long as we're wary about shipping any such in core. In passing, this patch allows aggregate function arguments to be named, to the extent of remembering the names in pg_proc and dumping them in pg_dump. You can't yet call an aggregate using named-parameter notation. That seems like a likely future extension, but it'll take some work, and it's not what this patch is really about. Likewise, there's still some work needed to make window functions handle VARIADIC fully, but I left that for another day. initdb forced because of new aggvariadic field in Aggref parse nodes.
-
由 Alvaro Herrera 提交于
-
由 Bruce Momjian 提交于
-
由 Bruce Momjian 提交于
per suggestion from Francisco Olart
-
- 03 9月, 2013 5 次提交
-
-
由 Robert Haas 提交于
MauMau
-
由 Greg Stark 提交于
-
由 Heikki Linnakangas 提交于
Also line-wrap an over-wide line in a comment that's ignored by pgindent.
-
由 Tom Lane 提交于
DST law changes in Israel, Morocco, Palestine, Paraguay. Historical corrections for Macquarie Island.
-
由 Andrew Dunstan 提交于
The original query ignored TOAST tables which could result in tables needing a vacuum not being reported. Backpatch to all live branches.
-
- 02 9月, 2013 2 次提交
-
-
由 Peter Eisentraut 提交于
-
由 Tom Lane 提交于
It seems like a good idea to update these examples since some fairly basic planner behaviors have changed in 9.3; notably that the startup cost for an indexscan plan node is no longer invariably estimated at 0.00.
-