- 18 3月, 2013 1 次提交
-
-
由 Tom Lane 提交于
We had two copies of this function in the backend and libpq, which was already pretty bogus, but it turns out that we need it in some other programs that don't use libpq (such as pg_test_fsync). So put it where it probably should have been all along. The signal-mask-initialization support in src/backend/libpq/pqsignal.c stays where it is, though, since we only need that in the backend.
-
- 17 3月, 2013 3 次提交
-
-
由 Tom Lane 提交于
This GUC allows limiting the time spent waiting to acquire any one heavyweight lock. In support of this, improve the recently-added timeout infrastructure to permit efficiently enabling or disabling multiple timeouts at once. That reduces the performance hit from turning on lock_timeout, though it's still not zero. Zoltán Böszörményi, reviewed by Tom Lane, Stephen Frost, and Hari Babu
-
由 Peter Eisentraut 提交于
-
由 Peter Eisentraut 提交于
-
- 16 3月, 2013 2 次提交
-
-
由 Tom Lane 提交于
Clarify the docs explaining what commit_delay does, and add a recommendation about a useful value for it, namely half of the single-page fsync time reported by pg_test_fsync. This is informed by testing of the new-in-9.3 implementation of commit_delay; in prior versions it was far harder to arrive at a useful setting. In passing, do some wordsmithing and markup-fixing in the same general area. Also, change pg_test_fsync's default time-per-test from 2 seconds to 5. The old value was about the minimum at which the results could be taken seriously at all, and so seems a tad optimistic as a default. Peter Geoghegan, reviewed by Noah Misch; some additional editing by me
-
由 Tom Lane 提交于
Formerly we just Assert'ed that each refcount was zero, which was quick and easy but failed to provide a good overview of what was wrong. Change the code so that we'll call PrintBufferLeakWarning() for each buffer with a nonzero refcount, and then Assert at the end of the loop. This costs nothing in runtime and might ease diagnosis of some bugs. Greg Smith, reviewed by Satoshi Nagayasu, further tweaked by me
-
- 15 3月, 2013 8 次提交
-
-
由 Tom Lane 提交于
This change adds some more standard sprintf() functionality to format(). Pavel Stehule, reviewed by Dean Rasheed and Kyotaro Horiguchi
-
由 Tom Lane 提交于
This was discussed in connection with the patch to avoid inserting no-op Result nodes, but not actually implemented therein.
-
由 Kevin Grittner 提交于
Due to a misreading of the function's comment block, there was an unneeded change to a call in rewriteDefine.c. There is, in fact no reason to pass false for a MV; it should be true just like a view. Fixes issue pointed out by Tom Lane
-
由 Kevin Grittner 提交于
This would have caught a bug in the initial patch, and seems like a good thing to test going forward. Per bug report by Erik Rijkers and fix by Tom Lane
-
由 Heikki Linnakangas 提交于
Even though this patch had no user-visible difference, better keep the code in psqlscan.l sync with the backend lexer. And of course it's nice to shrink the psql binary, too. Ecpg's version of the lexer doesn't have the error rule, it doesn't try to avoid backing up, so it doesn't need to be modified. As reminded by Tom Lane
-
由 Tom Lane 提交于
Fix unportable use of isdigit(), get rid of useless calculations.
-
由 Tom Lane 提交于
The planner sometimes inserts Result nodes to perform column projections (ie, arbitrary scalar calculations) above plan nodes that lack projection logic of their own. However, we did that even if the lower plan node was in fact producing the required column set already; which is a pretty common case given the popularity of "SELECT * FROM ...". Measurements show that the useless plan node adds non-negligible overhead, especially when there are many columns in the result. So add a check to avoid inserting a Result node unless there's something useful for it to do. There are a couple of remaining places where unnecessary Result nodes could get inserted, but they are (a) much less performance-critical, and (b) coded in such a way that it's hard to avoid inserting a Result, because the desired tlist is changed on-the-fly in subsequent logic. We'll leave those alone for now. Kyotaro Horiguchi; reviewed and further hacked on by Amit Kapila and Tom Lane.
-
由 Heikki Linnakangas 提交于
The error rule used to avoid backtracking with the U&'...' UESCAPE 'x' syntax bloated the flex tables, so refactor that. This patch makes the error rule shorter, by introducing a new exclusive flex state that's entered after parsing U&'...'. This shrinks the postgres binary by about 220kB.
-
- 14 3月, 2013 4 次提交
-
-
由 Heikki Linnakangas 提交于
The estimates are based on the existing lower bound histogram, and a new histogram of range lengths. Bump catversion, because the range length histogram now needs to be present in statistic slot kind 6, or you get an error on @> and <@ queries. (A re-ANALYZE would be enough to fix that, though) Alexander Korotkov, with some refactoring by me.
-
由 Peter Eisentraut 提交于
Pavel Stěhule
-
由 Kevin Grittner 提交于
Reports and suggested patches from Fujii Masao and Andrew Dunstan. Andrew Dunstan
-
由 Tom Lane 提交于
Treat expressions as being remotely executable only if all collations used in them are determined by Vars of the foreign table. This means that, if the foreign server gets different answers than we do, it's the user's fault for not having marked the foreign table columns with collations equivalent to the remote table's. This rule allows most simple expressions such as "var < 'constant'" to be sent to the remote side, because the constant isn't determining the collation (the Var's collation would win). There's still room for improvement, but it's hard to see how to do it without a lot more knowledge and/or assumptions about what the remote side will do.
-
- 13 3月, 2013 3 次提交
-
-
由 Tom Lane 提交于
Mention that PlanForeignModify's result must be copiable by copyObject.
-
由 Tom Lane 提交于
Adopt the position that only locally-defined defaults matter. Any defaults defined in the remote database do not affect insertions performed through a foreign table (unless they are for columns not known to the foreign table). While it'd arguably be more useful to permit remote defaults to be used, making that work in a consistent fashion requires far more work than seems possible for 9.3.
-
由 Tom Lane 提交于
There's still some discussion about exactly how postgres_fdw ought to handle this case, but there seems no debate that we want to allow defaults to be used for inserts into foreign tables. So remove the core-code restrictions that prevented it. While at it, get rid of the special grammar productions for CREATE FOREIGN TABLE, and instead add explicit FEATURE_NOT_SUPPORTED error checks for the disallowed cases. This makes the grammar a shade smaller, and more importantly results in much more intelligible error messages for unsupported cases. It's also one less thing to fix if we ever start supporting constraints on foreign tables.
-
- 12 3月, 2013 5 次提交
-
-
由 Alvaro Herrera 提交于
Apparently I lost some of the edits I had done on this page for commit 0ac5ad51. Per note from Etsuro Fujita, although I didn't use his patch. Make some of the wording in the affected section a bit more complete, too.
-
由 Tom Lane 提交于
A test intended to provoke an error on the remote side was coded in such a way that multiple rows should be updated, so the output would vary depending on which one was processed first. Per buildfarm.
-
由 Tom Lane 提交于
For datatypes whose output formatting depends on one or more GUC settings, we have to worry about whether the other server will interpret the value the same way it was meant. pg_dump has been aware of this hazard for a long time, but postgres_fdw needs to deal with it too. To fix data retrieval from the remote server, set the necessary remote GUC settings at connection startup. (We were already assuming that settings made then would persist throughout the remote session.) To fix data transmission to the remote server, temporarily force the relevant GUCs to the right values when we're about to convert any data values to text for transmission. This is all pretty grotty, and not very cheap either. It's tempting to think of defining one uber-GUC that would override any settings that might render printed data values unportable. But of course, older remote servers wouldn't know any such thing and would still need this logic. While at it, revert commit f7951eef, since this provides a real fix. (The timestamptz given in the error message returned from the "remote" server will now reliably be shown in UTC.)
-
由 Tom Lane 提交于
"INSERT INTO foo() VALUES ()" is invalid syntax, so don't do that.
-
由 Tom Lane 提交于
"break" instead of "continue" suppressed view expansion for views appearing later in the range table. Per report from Erikjan Rijkers. While at it, improve the associated comment a bit.
-
- 11 3月, 2013 6 次提交
-
-
由 Andrew Dunstan 提交于
This adds the following: json_agg(anyrecord) -> json to_json(any) -> json hstore_to_json(hstore) -> json (also used as a cast) hstore_to_json_loose(hstore) -> json The last provides heuristic treatment of numbers and booleans. Also, in json generation, if any non-builtin type has a cast to json, that function is used instead of the type's output function. Andrew Dunstan, reviewed by Steve Singer. Catalog version bumped.
-
由 Peter Eisentraut 提交于
suggested by Tianyin Xu
-
由 Peter Eisentraut 提交于
-
由 Peter Eisentraut 提交于
-
由 Tom Lane 提交于
We probably need to tell the remote server to use specific timezone and datestyle settings, and maybe other things. But for now let's just hack the postgres_fdw regression test to not provoke failures when run in non-EST5EDT environments. Per buildfarm.
-
由 Tom Lane 提交于
This patch adds the core-system infrastructure needed to support updates on foreign tables, and extends contrib/postgres_fdw to allow updates against remote Postgres servers. There's still a great deal of room for improvement in optimization of remote updates, but at least there's basic functionality there now. KaiGai Kohei, reviewed by Alexander Korotkov and Laurenz Albe, and rather heavily revised by Tom Lane.
-
- 10 3月, 2013 1 次提交
-
-
由 Magnus Hagander 提交于
Instead of just reporting which user failed to log in, log both the line number in the active pg_hba.conf file (which may not match reality in case the file has been edited and not reloaded) and the contents of the matching line (which will always be correct), to make it easier to debug incorrect pg_hba.conf files. The message to the client remains unchanged and does not include this information, to prevent leaking security sensitive information. Reviewed by Tom Lane and Dean Rasheed
-
- 08 3月, 2013 5 次提交
-
-
由 Heikki Linnakangas 提交于
-
由 Heikki Linnakangas 提交于
Alexander Korotkov, reviewed by Jeff Davis.
-
由 Heikki Linnakangas 提交于
The libpgcommon patch made that unnecessary, palloc and friends are now available in frontend programs too, mapped to plain old malloc. As pointed out by Alvaro Herrera.
-
由 Kevin Grittner 提交于
Fujii Masao
-
由 Tom Lane 提交于
The previous coding of this function could get into situations where it would never terminate, because successive passes would re-add EMPTY arcs that had been removed by the previous pass. Rewrite the function completely using a new algorithm that is guaranteed to terminate, and also seems to be usually faster than the old one. Per Tcl bugs 3604074 and 3606683. Tom Lane and Don Porter
-
- 07 3月, 2013 2 次提交
-
-
由 Heikki Linnakangas 提交于
If we were about to enter archive recovery after crash recovery, we scanned the archive for the latest tli history file, and set the recovery target timeline to that. However, when we actually tried to read the history file, we would not fetch the file from the archive, because we were not in archive recovery yet. To fix, make readTimeLineHistory and existsTimeLineHistory to always fetch the file from archive if archive recovery is requested, even if we're not in archive recovery yet. Backpatch to 9.2. Mitsumasa KONDO
-
由 Tom Lane 提交于
This saves several catalog lookups per reference. It's not all that exciting right now, because we'd managed to minimize the number of places that need to fetch the data; but the upcoming writable-foreign-tables patch needs this info in a lot more places.
-