- 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
-
- 12 9月, 2013 1 次提交
-
-
由 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.
-
- 11 9月, 2013 4 次提交
-
-
由 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 1 次提交
-
-
由 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 3 次提交
-
-
由 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.
-
由 Bruce Momjian 提交于
Previous text was "No description available". Tianyin Xu
-
由 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 5 次提交
-
-
由 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 提交于
-
- 03 9月, 2013 2 次提交
-
-
由 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.
-
- 02 9月, 2013 1 次提交
-
-
由 Peter Eisentraut 提交于
-
- 31 8月, 2013 3 次提交
-
-
由 Tom Lane 提交于
The previous version of the query disregarded the result of the MergeAppend instead of checking its results. Andres Freund
-
由 Tom Lane 提交于
Per Andres Freund.
-
由 Tom Lane 提交于
Failing to do so can cause queries to return wrong data, error out or crash. This requires adding a new binaryheap_reset() method to binaryheap.c, but that probably should have been there anyway. Per bug #8410 from Terje Elde. Diagnosis and patch by Andres Freund.
-
- 30 8月, 2013 1 次提交
-
-
由 Alvaro Herrera 提交于
-
- 29 8月, 2013 3 次提交
-
-
由 Heikki Linnakangas 提交于
Testing done in 2011 by Tom Lane concluded that this is a win on Intel Xeons and AMD Opterons, but it was not changed back then, because of an old comment in tas() that suggested that it's a huge loss on older Opterons. However, didn't have separate TAS() and TAS_SPIN() macros back then, so the comment referred to doing a non-locked initial test even on the first access, in uncontended case. I don't have access to older Opterons, but I'm pretty sure that doing an initial unlocked test is unlikely to be a loss while spinning, even though it might be for the first access. We probably should do the same on 32-bit x86, but I'm afraid of changing it without any testing. Hence just add a note to the x86 implementation suggesting that we probably should do the same there.
-
由 Robert Haas 提交于
Using the infrastructure provided by this patch, it's possible either to wait for the startup of a dynamically-registered background worker, or to poll the status of such a worker without waiting. In either case, the current PID of the worker process can also be obtained. As usual, worker_spi is updated to demonstrate the new functionality. Patch by me. Review by Andres Freund.
-
由 Robert Haas 提交于
As noted by Tom Lane, commit 813fb031 was overly optimistic about how safe it is to concurrently change enumsortorder values under MVCC catalog scan semantics. Restore some of the previous text, with hopefully-correct adjustments for the new state of play.
-
- 28 8月, 2013 3 次提交
-
-
由 Heikki Linnakangas 提交于
We already did this for -t (--table) in 9.3, but missed the other similar options. For consistency, allow all of them to be specified multiple times. Unfortunately it's too late to sneak this into 9.3, so commit to master only.
-
由 Alvaro Herrera 提交于
Andres Freund; bug detected by valgrind
-
由 Alvaro Herrera 提交于
-
- 25 8月, 2013 1 次提交
-
-
由 Tom Lane 提交于
The previous coding in plancache.c essentially used 10% of the estimated runtime as its cost estimate for planning. This can be pretty bogus, especially when the estimated runtime is very small, such as in a simple expression plan created by plpgsql, or a simple INSERT ... VALUES. While we don't have a really good handle on how planning time compares to runtime, it seems reasonable to use an estimate based on the number of relations referenced in the query, with a rather large multiplier. This patch uses 1000 * cpu_operator_cost * (nrelations + 1), so that even a trivial query will be charged 1000 * cpu_operator_cost for planning. This should address the problem reported by Marc Cousin and others that 9.2 and up prefer custom plans in cases where the planning time greatly exceeds what can be saved.
-
- 24 8月, 2013 2 次提交
-
-
由 Magnus Hagander 提交于
The backup will not work (without a logarchive, and that's the whole point of -x) in this case, this patch just changes it to throw an error instead of crashing when this happens. Noticed and diagnosed by TAKATSUKA Haruka
-
由 Tom Lane 提交于
It's possible that inlining of SQL functions (or perhaps other changes?) has exposed typmod information not known at parse time. In such cases, Vars generated by query_planner might have valid typmod values while the original grouping columns only have typmod -1. This isn't a semantic problem since the behavior of grouping only depends on type not typmod, but it breaks locate_grouping_columns' use of tlist_member to locate the matching entry in query_planner's result tlist. We can fix this without an excessive amount of new code or complexity by relying on the fact that locate_grouping_columns only gets called when make_subplanTargetList has set need_tlist_eval == false, and that can only happen if all the grouping columns are simple Vars. Therefore we only need to search the sub_tlist for a matching Var, and we can reasonably define a "match" as being a match of the Var identity fields varno/varattno/varlevelsup. The code still Asserts that vartype matches, but ignores vartypmod. Per bug #8393 from Evan Martin. The added regression test case is basically the same as his example. This has been broken for a very long time, so back-patch to all supported branches.
-
- 22 8月, 2013 1 次提交
-
-
由 Tom Lane 提交于
We should account for the per-group hashtable entry overhead when considering whether to use a hash aggregate to implement DISTINCT. The comparable logic in choose_hashed_grouping() gets this right, but I think I omitted it here in the mistaken belief that there would be no overhead if there were no aggregate functions to be evaluated. This can result in more than 2X underestimate of the hash table size, if the tuples being aggregated aren't very wide. Per report from Tomas Vondra. This bug is of long standing, but per discussion we'll only back-patch into 9.3. Changing the estimation behavior in stable branches seems to carry too much risk of destabilizing plan choices for already-tuned applications.
-