- 20 12月, 2010 1 次提交
-
-
由 Tom Lane 提交于
After parsing a parenthesized subexpression, we must pop all pending ANDs and NOTs off the stack, just like the case for a simple operand. Per bug #5793. Also fix clones of this routine in contrib/intarray and contrib/ltree, where input of types query_int and ltxtquery had the same problem. Back-patch to all supported versions.
-
- 18 12月, 2010 1 次提交
-
-
由 Magnus Hagander 提交于
Add a note to user-facing parameters that can be removed completely (and not just empty) by #ifdef's depending on build configuration.
-
- 16 12月, 2010 2 次提交
-
-
由 Tom Lane 提交于
The mingw people don't appear to care about compatibility with non-GNU versions of getopt, so force use of our own copy of getopt on Windows. Also, ensure that we make use of optreset when using our own copy. Per report from Andrew Dunstan. Back-patch to all versions supported on Windows.
-
由 Tom Lane 提交于
Fix the same size_alpha versus size_beta typo that was recently fixed in contrib/cube. Noted by Alexander Korotkov. Back-patch to all supported branches (there is a more invasive fix in HEAD).
-
- 14 12月, 2010 5 次提交
-
-
由 Marc G. Fournier 提交于
-
由 Marc G. Fournier 提交于
-
由 Tom Lane 提交于
-
由 Peter Eisentraut 提交于
-
由 Tom Lane 提交于
Fiji and Samoa. Historical corrections for Hong Kong.
-
- 09 12月, 2010 1 次提交
-
-
由 Tom Lane 提交于
Recent versions of the Linux system header files cause xlogdefs.h to believe that open_datasync should be the default sync method, whereas formerly fdatasync was the default on Linux. open_datasync is a bad choice, first because it doesn't actually outperform fdatasync (in fact the reverse), and second because we try to use O_DIRECT with it, causing failures on certain filesystems (e.g., ext4 with data=journal option). This part of the patch is largely per a proposal from Marti Raudsepp. More extensive changes are likely to follow in HEAD, but this is as much change as we want to back-patch. Also clean up confusing code and incorrect documentation surrounding the fsync_writethrough option. Those changes shouldn't result in any actual behavioral change, but I chose to back-patch them anyway to keep the branches looking similar in this area. In 9.0 and HEAD, also do some copy-editing on the WAL Reliability documentation section. Back-patch to all supported branches, since any of them might get used on modern Linux versions.
-
- 07 12月, 2010 1 次提交
-
-
由 Tom Lane 提交于
There are some code paths, such as SPI_execute(), where we invoke copyObject() on raw parse trees before doing parse analysis on them. Since the bison grammar is capable of building heavily nested parsetrees while itself using only minimal stack depth, this means that copyObject() can be the front-line function that hits stack overflow before anything else does. Accordingly, it had better have a check_stack_depth() call. I did a bit of performance testing and found that this slows down copyObject() by only a few percent, so the hit ought to be negligible in the context of complete processing of a query. Per off-list report from Toshihide Katayama. Back-patch to all supported branches.
-
- 01 12月, 2010 1 次提交
-
-
由 Tom Lane 提交于
There were corner cases in which the planner would attempt to inline such a function, which would result in a failure at runtime due to loss of information about exactly what the result record type is. Fix by disabling inlining when the function's recorded result type is RECORD. There might be some sub-cases where inlining could still be allowed, but this is a simple and backpatchable fix, so leave refinements for another day. Per bug #5777 from Nate Carson. Back-patch to all supported branches. 8.1 happens to avoid a core-dump here, but it still does the wrong thing.
-
- 27 11月, 2010 1 次提交
-
-
由 Tom Lane 提交于
Most of the functions that execute XPath queries leaked the data structures created by libxml2. This memory would not be recovered until end of session, so it mounts up pretty quickly in any serious use of the feature. Per report from Pavel Stehule, though this isn't his patch. Back-patch to all supported branches.
-
- 25 11月, 2010 1 次提交
-
-
由 Itagaki Takahiro 提交于
except creating new connections.
-
- 20 11月, 2010 1 次提交
-
-
由 Tom Lane 提交于
When using default autovacuum_vac_cost_limit, autovac_balance_cost relied on VacuumCostLimit to contain the correct global value ... but after the first time through in a particular worker process, it didn't, because we'd trashed it in previous iterations. Depending on the state of other autovac workers, this could result in a steady reduction of the effective cost_limit setting as a particular worker processed more and more tables, causing it to go slower and slower. Spotted by Simon Poole (bug #5759). Fix by saving and restoring the GUC variables in the loop in do_autovacuum. In passing, improve a few comments. Back-patch to 8.3 ... the cost rebalancing code has been buggy since it was put in.
-
- 16 11月, 2010 2 次提交
-
-
由 Heikki Linnakangas 提交于
temporary indexes are not WAL-logged. We used a constant LSN for temporary indexes, on the assumption that we don't need to worry about concurrent page splits in temporary indexes because they're only visible to the current session. But that assumption is wrong, it's possible to insert rows and split pages in the same session, while a scan is in progress. For example, by opening a cursor and fetching some rows, and INSERTing new rows before fetching some more. Fix by generating fake increasing LSNs, used in place of real LSNs in temporary GiST indexes.
-
由 Tom Lane 提交于
We must stay in the function's SPI context until done calling the iterator that returns the set result. Otherwise, any attempt to invoke SPI features in the python code called by the iterator will malfunction. Diagnosis and patch by Jan Urbanski, per bug report from Jean-Baptiste Quenot. Back-patch to 8.2; there was no support for SRFs in previous versions of plpython.
-
- 15 11月, 2010 1 次提交
-
-
由 Robert Haas 提交于
Alexander Korotkov
-
- 13 11月, 2010 2 次提交
-
-
由 Tom Lane 提交于
This is needed to support debug_print_parse, per report from Jon Nelson. Cursory testing via the regression tests suggests we aren't missing anything else.
-
由 Tom Lane 提交于
Once we have found a non-null constant argument, there is no need to examine additional arguments of the COALESCE. The previous coding got it right only if the constant was in the first argument position; otherwise it tried to simplify following arguments too, leading to unexpected behavior like this: regression=# select coalesce(f1, 42, 1/0) from int4_tbl; ERROR: division by zero It's a minor corner case, but a bug is a bug, so back-patch all the way.
-
- 12 11月, 2010 1 次提交
-
-
由 Heikki Linnakangas 提交于
location read from backup label file can be found: wasShutdown was set incorrectly when a backup label file was found. Jeff Davis, with a little tweaking by me.
-
- 11 11月, 2010 1 次提交
-
-
由 Tom Lane 提交于
This code was just plain wrong: what you got was not a line through the given point but a line almost indistinguishable from the Y-axis, although not truly vertical. The only caller that tries to use this function with m == DBL_MAX is dist_ps_internal for the case where the lseg is horizontal; it would end up producing the distance from the given point to the place where the lseg's line crosses the Y-axis. That function is used by other operators too, so there are several operators that could compute wrong distances from a line segment to something else. Per bug #5745 from jindiax. Back-patch to all supported branches.
-
- 10 11月, 2010 1 次提交
-
-
由 Tom Lane 提交于
The general design of memory management in Postgres is that intermediate results computed by an expression are not freed until the end of the tuple cycle. For expression indexes, ANALYZE has to re-evaluate each expression for each of its sample rows, and it wasn't bothering to free intermediate results until the end of processing of that index. This could lead to very substantial leakage if the intermediate results were large, as in a recent example from Jakub Ouhrabka. Fix by doing ResetExprContext for each sample row. This necessitates adding a datumCopy step to ensure that the final expression value isn't recycled too. Some quick testing suggests that this change adds at worst about 10% to the time needed to analyze a table with an expression index; which is annoying, but seems a tolerable price to pay to avoid unexpected out-of-memory problems. Back-patch to all supported branches.
-
- 09 11月, 2010 2 次提交
-
-
由 Heikki Linnakangas 提交于
length stored in the line pointer the same way it's calculated in the normal heap_insert() codepath. As noted by Jeff Davis, the length stored by raw_heap_insert() included padding but the one stored by the normal codepath did not. While the mismatch seems to be harmless, inconsistency isn't good, and the normal codepath has received a lot more testing over the years. Backpatch to 8.3 where the heap rewrite code was introduced.
-
由 Tom Lane 提交于
The original coding in FileClose() reset the file-is-temp flag before unlinking the file, so that if control came back through due to an error, it wouldn't try to unlink the file twice. This was correct when written, but when the log_temp_files feature was added, the logging action was put in between those two steps. An error occurring during the logging action --- such as a query cancel --- would result in the unlink not getting done at all, as in recent report from Michael Glaesemann. To fix this, make sure that we do both the stat and the unlink before doing anything that could conceivably CHECK_FOR_INTERRUPTS. There is a judgment call here, which is which log message to emit first: if you can see only one, which should it be? I chose to log unlink failure at the risk of losing the log_temp_files log message --- after all, if the unlink does fail, the temp file is still there for you to see. Back-patch to all versions that have log_temp_files. The code was OK before that.
-
- 07 11月, 2010 1 次提交
-
-
由 Tom Lane 提交于
Per recent investigation, the register stack can grow faster than the regular stack depending on compiler and choice of options. To avoid crashes we must check both stacks in check_stack_depth(). Back-patch to all supported versions.
-
- 04 11月, 2010 1 次提交
-
-
由 Tom Lane 提交于
Some buildfarm members fail the test with the original depth of 10 levels, apparently because they are running at the minimum max_stack_depth setting of 100kB and using ~ 10k per recursion level. While it might be interesting to try to figure out why they're eating so much stack, it isn't likely that any fix for that would be back-patchable. So just change the test to recurse only 5 levels. The extra levels don't prove anything correctness-wise anyway.
-
- 03 11月, 2010 1 次提交
-
-
由 Tom Lane 提交于
We failed to record any dependency on the underlying table for an index declared like "create index i on t (foo(t.*))". This would create trouble if the table were dropped without previously dropping the index. To fix, simplify some overly-cute code in index_create(), accepting the possibility that sometimes the whole-table dependency will be redundant. Also document this hazard in dependency.c. Per report from Kevin Grittner. In passing, prevent a core dump in pg_get_indexdef() if the index's table can't be found. I came across this while experimenting with Kevin's example. Not sure it's a real issue when the catalogs aren't corrupt, but might as well be cautious. Back-patch to all supported versions.
-
- 29 10月, 2010 1 次提交
-
-
由 Tom Lane 提交于
In general, expression execution state trees aren't re-entrantly usable, since functions can store private state information in them. For efficiency reasons, plpgsql tries to cache and reuse state trees for "simple" expressions. It can get away with that most of the time, but it can fail if the state tree is dirty from a previous failed execution (as in an example from Alvaro) or is being used recursively (as noted by me). Fix by tracking whether a state tree is in use, and falling back to the "non-simple" code path if so. This results in a pretty considerable speed hit when the non-simple path is taken, but the available alternatives seem even more unpleasant because they add overhead in the simple path. Per idea from Heikki. Back-patch to all supported branches.
-
- 28 10月, 2010 1 次提交
-
-
由 Heikki Linnakangas 提交于
after accepting a connection fails, and the server is compiled with GSSAPI support. Report and patch by Alexander V. Chernikov, bug #5731.
-
- 27 10月, 2010 1 次提交
-
-
由 Heikki Linnakangas 提交于
that WAL file containing the checkpoint redo-location can be found. This avoids making the cluster irrecoverable if the redo location is in an earlie WAL file than the checkpoint record. Report, analysis and patch by Jeff Davis, with small changes by me.
-
- 21 10月, 2010 1 次提交
-
-
由 Heikki Linnakangas 提交于
following NULL check was never reached. This problem was found by Coccinelle (null_ref.cocci from coccicheck). Marti Raudsepp
-
- 20 10月, 2010 1 次提交
-
-
由 Tom Lane 提交于
The trick is to not try to build executables directly from .c files, but to always build the intermediate .o files. For obscure reasons, Darwin's version of gcc will leave debug cruft behind in the first case but not the second. Per complaint from Robert Haas.
-
- 19 10月, 2010 1 次提交
-
-
由 Bruce Momjian 提交于
recent wal_sync_method doc paragraph to be clearer.
-
- 12 10月, 2010 1 次提交
-
-
由 Tom Lane 提交于
The original coding was quite sloppy about handling the case where XLogReadBuffer fails (because the page has since been deleted). This would result in either "bad buffer id: 0" or an Assert failure during replay, if indeed the page were no longer there. In a couple of places it also neglected to check whether the change had already been applied, which would probably result in corrupted index contents. I believe that bug #5703 is an instance of the first problem. These issues could show up without replication, but only if you were unfortunate enough to crash between modification of a GIN index and the next checkpoint. Back-patch to 8.2, which is as far back as GIN has WAL support.
-
- 08 10月, 2010 2 次提交
-
-
由 Robert Haas 提交于
-
由 Robert Haas 提交于
In particular, we are now more explicit about the fact that you may need wal_sync_method=fsync_writethrough for crash-safety on some platforms, including MaxOS X. There's also now an explicit caution against assuming that the default setting of wal_sync_method is either crash-safe or best for performance.
-
- 03 10月, 2010 1 次提交
-
-
由 Tom Lane 提交于
In versions 8.2 and up, the grammar allows attaching ORDER BY, LIMIT, FOR UPDATE, or WITH to VALUES, and hence to INSERT ... VALUES. But the special-case code for VALUES in transformInsertStmt() wasn't expecting any of those, and just ignored them, leading to unexpected results. Rather than complicate the special-case path, just ensure that the presence of any of those clauses makes us treat the query as if it had a general SELECT. Per report from Hitoshi Harada.
-
- 01 10月, 2010 2 次提交
-
-
由 Marc G. Fournier 提交于
-
由 Tom Lane 提交于
There are numerous methods by which a Perl or Tcl function can subvert the behavior of another such function executed later; for example, by redefining standard functions or operators called by the target function. If the target function is SECURITY DEFINER, or is called by such a function, this means that any ordinary SQL user with Perl or Tcl language usage rights can do essentially anything with the privileges of the target function's owner. To close this security hole, create a separate Perl or Tcl interpreter for each SQL userid under which plperl or pltcl functions are executed within a session. However, all plperlu or pltclu functions run within a session still share a single interpreter, since they all execute at the trust level of a database superuser anyway. Note: this change results in a functionality loss when libperl has been built without the "multiplicity" option: it's no longer possible to call plperl functions under different userids in one session, since such a libperl can't support multiple interpreters in one process. However, such a libperl already failed to support concurrent use of plperl and plperlu, so it's likely that few people use such versions with Postgres. Security: CVE-2010-3433
-