- 17 7月, 2012 3 次提交
-
-
由 Peter Eisentraut 提交于
The Solaris Studio compiler warns about these instances, unlike more mainstream compilers such as gcc. But manual inspection showed that the code is clearly not reachable, and we hope no worthy compiler will complain about removing this code.
-
由 Peter Eisentraut 提交于
-
由 Tom Lane 提交于
Formerly, when trying to copy both indexes and comments, CREATE TABLE LIKE had to pre-assign names to indexes that had comments, because it made up an explicit CommentStmt command to apply the comment and so it had to know the name for the index. This creates bad interactions with other indexes, as shown in bug #6734 from Daniele Varrazzo: the preassignment logic couldn't take any other indexes into account so it could choose a conflicting name. To fix, add a field to IndexStmt that allows it to carry a comment to be assigned to the new index. (This isn't a user-exposed feature of CREATE INDEX, only an internal option.) Now we don't need preassignment of index names in any situation. I also took the opportunity to refactor DefineIndex to accept the IndexStmt as such, rather than passing all its fields individually in a mile-long parameter list. Back-patch to 9.2, but no further, because it seems too dangerous to change IndexStmt or DefineIndex's API in released branches. The bug exists back to 9.0 where CREATE TABLE LIKE grew the ability to copy comments, but given the lack of prior complaints we'll just let it go unfixed before 9.2.
-
- 16 7月, 2012 1 次提交
-
-
由 Tom Lane 提交于
rfree() failed to cope with the case that pg_regcomp() had initialized the regex_t struct but then failed to allocate any memory for re->re_guts (ie, the first malloc call in pg_regcomp() failed). It would try to touch the guts struct anyway, and thus dump core. This is a sufficiently narrow corner case that it's not surprising it's never been seen in the field; but still a bug is a bug, so patch all active branches. Noted while investigating whether we need to call pg_regfree after a failure return from pg_regcomp. Other than this bug, it turns out we don't, so adjust comments appropriately.
-
- 15 7月, 2012 1 次提交
-
-
由 Heikki Linnakangas 提交于
This was causing a compiler warning with Solaris compiler. Use 0 instead. The variable is initialized just for the sake of tidyness and/or debugging, it's not used for anything before setting it to a real value. Per report and suggestion from Peter Eisentraut.
-
- 14 7月, 2012 3 次提交
-
-
由 Heikki Linnakangas 提交于
This makes it easier to determine how far back you need to keep archived WAL files, to restore from a backup. Fujii Masao
-
由 Peter Eisentraut 提交于
-
由 Tom Lane 提交于
Historically we have not worried about fsync'ing anything during initdb (in fact, initdb intentionally passes -F to each backend launch to prevent it from fsync'ing). But with filesystems getting more aggressive about caching data, that's not such a good plan anymore. Make initdb do a pass over the finished data directory tree to fsync everything. For testing purposes, the -N/--nosync flag can be used to restore the old behavior. Also, testing shows that on Linux, sync_file_range() is much faster than posix_fadvise() for hinting to the kernel that an fsync is coming, apparently because the latter blocks on a rather small request queue while the former doesn't. So use this function if available in initdb, and also in the backend's pg_flush_data() (where it currently will affect only the speed of CREATE DATABASE's cloning step). We will later make pg_regress invoke initdb with the --nosync flag to avoid slowing down cases such as "make check" in contrib. But let's not do so until we've shaken out any portability issues in this patch. Jeff Davis, reviewed by Andres Freund
-
- 13 7月, 2012 4 次提交
-
-
由 Tom Lane 提交于
Make it clearer that the passed stack mustn't be empty, and that we are not supposed to fall off the end of the stack in the main loop. Tighten the loop that extracts the root block number, too. Markus Wanner and Tom Lane
-
由 Peter Eisentraut 提交于
found by P. Broennimann
-
由 Tom Lane 提交于
When reading from a text- or CSV-format file in file_fdw, the datatype input routines can consume a significant fraction of the runtime. Often, the query does not need all the columns, so we can get a useful speed boost by skipping I/O conversion for unnecessary columns. To support this, add a "convert_selectively" option to the core COPY code. This is undocumented and not accessible from SQL (for now, anyway). Etsuro Fujita, reviewed by KaiGai Kohei
-
由 Bruce Momjian 提交于
Dunstan.
-
- 12 7月, 2012 2 次提交
-
-
由 Magnus Hagander 提交于
When the internal loop mode was added, freeing memory and closing filedescriptors before returning became important, and a few cases in the code missed that. Fujii Masao
-
由 Tom Lane 提交于
These functions support removing or replacing array element value(s) matching a given search value. Although intended mainly to support a future array-foreign-key feature, they seem useful in their own right. Marco Nenciarini and Gabriele Bartolini, reviewed by Alex Hunsaker
-
- 11 7月, 2012 7 次提交
-
-
由 Bruce Momjian 提交于
pg_upgrade. Backpatch to 9.2.
-
由 Tom Lane 提交于
Per buildfarm complaints.
-
由 Tatsuo Ishii 提交于
source code(lisp/international/mule-conf.el). These charsets have not been supported up to now anyway, so this is just for adding commentary. Also add mention that we follow emacs's implementation, not xemacs's.
-
由 Tom Lane 提交于
Also some cosmetic improvements for wchar-to-mblen patch.
-
由 Alvaro Herrera 提交于
When in SQL_ASCII encoding, strings passed around are not necessarily UTF8-safe. We had already fixed this in some places, but it looks like we missed some. I had to backpatch Peter Eisentraut's a8b92b60 to 9.1 in order for this patch to cherry-pick more cleanly. Patch from Alex Hunsaker, tweaked by Kyotaro HORIGUCHI and myself. Some desultory cleanup and comment addition by me, during patch review. Per bug report from Christoph Berg in 20120209102116.GA14429@msgid.df7cb.de
-
由 Alvaro Herrera 提交于
-
由 Tom Lane 提交于
To generate btree-indexable conditions from regex WHERE conditions (such as WHERE indexed_col ~ '^foo'), we need to be able to identify any fixed prefix that a regex might have; that is, find any string that must be a prefix of all strings satisfying the regex. We used to do that with entirely ad-hoc code that looked at the source text of the regex. It didn't know very much about regex syntax, which mostly meant that it would fail to identify some optimizable cases; but Viktor Rosenfeld reported that it would produce actively wrong answers for quantified parenthesized subexpressions, such as '^(foo)?bar'. Rather than trying to extend the ad-hoc code to cover this, let's get rid of it altogether in favor of identifying prefixes by examining the compiled form of a regex. To do this, I've added a new entry point "pg_regprefix" to the regex library; hopefully it is defined in a sufficiently general fashion that it can remain in the library when/if that code gets split out as a standalone project. Since this bug has been there for a very long time, this fix needs to get back-patched. However it depends on some other recent commits (particularly the addition of wchar-to-database-encoding conversion), so I'll commit this separately and then go to work on back-porting the necessary fixes.
-
- 10 7月, 2012 1 次提交
-
-
由 Tom Lane 提交于
Previously, pattern_fixed_prefix() was defined to return whatever fixed prefix it could extract from the pattern, plus the "rest" of the pattern. That definition was sensible for LIKE patterns, but not so much for regexes, where reconstituting a valid pattern minus the prefix could be quite tricky (certainly the existing code wasn't doing that correctly). Since the only thing that callers ever did with the "rest" of the pattern was to pass it to like_selectivity() or regex_selectivity(), let's cut out the middle-man and just have pattern_fixed_prefix's subroutines do this directly. Then pattern_fixed_prefix can return a simple selectivity number, and the question of how to cope with partial patterns is removed from its API specification. While at it, adjust the API spec so that callers who don't actually care about the pattern's selectivity (which is a lot of them) can pass NULL for the selectivity pointer to skip doing the work of computing a selectivity estimate. This patch is only an API refactoring that doesn't actually change any processing, other than allowing a little bit of useless work to be skipped. However, it's necessary infrastructure for my upcoming fix to regex prefix extraction, because after that change there won't be any simple way to identify the "rest" of the regex, not even to the low level of fidelity needed by regex_selectivity. We can cope with that if regex_fixed_prefix and regex_selectivity communicate directly, but not if we have to work within the old API. Hence, back-patch to all active branches.
-
- 09 7月, 2012 1 次提交
-
-
由 Tom Lane 提交于
We can do this without creating an API break for estimation functions by passing the collation using the existing fmgr functionality for passing an input collation as a hidden parameter. The need for this was foreseen at the outset, but we didn't get around to making it happen in 9.1 because of the decision to sort all pg_statistic histograms according to the database's default collation. That meant that selectivity estimators generally need to use the default collation too, even if they're estimating for an operator that will do something different. The reason it's suddenly become more interesting is that regexp interpretation also uses a collation (for its LC_TYPE not LC_COLLATE property), and we no longer want to use the wrong collation when examining regexps during planning. It's not that the selectivity estimate is likely to change much from this; rather that we are thinking of caching compiled regexps during planner estimation, and we won't get the intended benefit if we cache them with a different collation than the executor will use. Back-patch to 9.1, both because the regexp change is likely to get back-patched and because we might as well get this right in all collation-supporting branches, in case any third-party code wants to rely on getting the collation. The patch turns out to be minuscule now that I've done it ...
-
- 08 7月, 2012 1 次提交
-
-
由 Tom Lane 提交于
The previous coding abused the first element of a cNFA state's arcs list to hold a per-state flag bit, which was confusing, undocumented, and not even particularly efficient. Get rid of that in favor of a separate "stflags" vector. Since there's only one bit in use, I chose to allocate a char per state; we could possibly replace this with a bitmap at some point, but that would make accesses a little slower. It's already about 8X smaller than before, so let's not get overly tense. Also document the representation better than it was before, which is to say not at all. This patch is a byproduct of investigations towards extracting a "fixed prefix" string from the compact-NFA representation of regex patterns. Might need to back-patch it if we decide to back-patch that fix, but for now it's just code cleanup so I'll just put it in HEAD.
-
- 07 7月, 2012 4 次提交
-
-
由 Alvaro Herrera 提交于
This should ease its use on the Windows build environment.
-
由 Alvaro Herrera 提交于
Commit 2b443063 changed wording for some of the error messages, but neglected updating the regress output to match.
-
由 Bruce Momjian 提交于
\copyright output to 2012. Backpatch to 9.2.
-
由 Bruce Momjian 提交于
to avoid producing dups, e.g. 2012-2012 Backpatch to 9.2.
-
- 06 7月, 2012 10 次提交
-
-
由 Bruce Momjian 提交于
match, so files that contain embedded copyrights are updated, e.g. pgsql/help.c. Backpatch to 9.2.
-
由 Bruce Momjian 提交于
basename() qualification.
-
由 Bruce Momjian 提交于
(now added). Backpatch to 9.2.
-
由 Bruce Momjian 提交于
-
由 Robert Haas 提交于
Bug spotted by Tom Lane.
-
由 Bruce Momjian 提交于
report from Tom. Backpatch to 9.2.
-
由 Tom Lane 提交于
join_path_components() tried to remove leading ".." components from its tail argument, but it was not nearly bright enough to do so correctly unless the head argument was (a) absolute and (b) canonicalized. Rather than try to fix that logic, let's just get rid of it: there is no correctness reason to remove "..", and cosmetic concerns can be taken care of by a subsequent canonicalize_path() call. Per bug #6715 from Greg Davidson. Back-patch to all supported branches. It appears that pre-9.2, this function is only used with absolute paths as head arguments, which is why we'd not noticed the breakage before. However, third-party code might be expecting this function to work in more general cases, so it seems wise to back-patch. In HEAD and 9.2, also make some minor cosmetic improvements to callers.
-
由 Heikki Linnakangas 提交于
That caused the plpython_unicode regression test to fail on SQL_ASCII encoding, as evidenced by the buildfarm. The reason is that with the patch, you don't get the detail in the error message that you got before. That detail is actually very informative, so rather than just adjust the expected output, let's revert that part of the patch for now to make the buildfarm green again, and figure out some other way to avoid the recursion of PLy_elog() that doesn't lose the detail.
-
由 Heikki Linnakangas 提交于
Windows encodings, "win1252" and so forth, are named differently in Python, like "cp1252". Also, if the PyUnicode_AsEncodedString() function call fails for some reason, use a plain ereport(), not a PLy_elog(), to report that error. That avoids recursion and crash, if PLy_elog() tries to call PLyUnicode_Bytes() again. This fixes bug reported by Asif Naeem. Backpatch down to 9.0, before that plpython didn't even try these conversions. Jan Urbański, with minor comment improvements by me.
-
由 Tom Lane 提交于
All Unix-oid platforms that we currently support should have waitpid(), since it's in V2 of the Single Unix Spec. Our git history shows that the wait3 code was added to support NextStep, which we officially dropped support for as of 9.2. So get rid of the configure test, and simplify the macro spaghetti in reaper(). Per suggestion from Fujii Masao.
-
- 05 7月, 2012 2 次提交
-
-
由 Alvaro Herrera 提交于
Currently only pg_clog is copied, but some other directories could need the same treatment as well, so create a subroutine to do it. Extracted from my (somewhat larger) FOR KEY SHARE patch.
-
由 Magnus Hagander 提交于
Dean Rasheed, reviewed by Josh Kupershmidt
-