- 29 1月, 2016 9 次提交
-
-
由 Robert Haas 提交于
This is following in a long train of similar changes and for the same reasons - see b319356f and fe702a7b inter alia. Author: Amit Kapila Reviewed-by: Alexander Korotkov, Robert Haas
-
由 Robert Haas 提交于
Previously, each PGPROC's backendLock was part of the main tranche, and the PGPROC just contained a pointer. Now, the actual LWLock is part of the PGPROC. As with previous, similar patches, this makes it significantly easier to identify these lwlocks in LWLOCK_STATS or Trace_lwlocks output and improves modularity. Author: Ildus Kurbangaliev Reviewed-by: Amit Kapila, Robert Haas
-
由 Alvaro Herrera 提交于
This doesn't add any functionality but just shuffles things around so that it can be reused and improved later. Author: Fabien Coelho Reviewed-by: Michael Paquier, Álvaro Herrera
-
由 Tom Lane 提交于
listForeignTables' invocation of processSQLNamePattern did not match up with the other ones that handle potentially-schema-qualified names; it failed to make use of pg_table_is_visible() and also passed the name arguments in the wrong order. Bug seems to have been aboriginal in commit 0d692a0d. It accidentally sort of worked as long as you didn't inquire too closely into the behavior, although the silliness was later exposed by inconsistencies in the test queries added by 59efda3e (which I probably should have questioned at the time, but didn't). Per bug #13899 from Reece Hart. Patch by Reece Hart and Tom Lane. Back-patch to all affected branches.
-
由 Fujii Masao 提交于
Patch-by: Oleksandr Shulgin Reviewed-by: Craig Ringer and Fujii Masao Backpatch-through: 9.4 where logical decoding was introduced
-
由 Robert Haas 提交于
The upcoming patch to allow join pushdown in postgres_fdw needs to use this code multiple times, which requires moving it to deparse.c. That seems like a good idea anyway, so do that now both on general principle and to simplify the future patch. Inspired by a patch by Shigeru Hanada and Ashutosh Bapat, but I did it a little differently than what that patch did.
-
由 Robert Haas 提交于
Previously, the foreign join pushdown infrastructure left the question of security entirely up to individual FDWs, but it would be easy for a foreign data wrapper to inadvertently open up subtle security holes that way. So, make it the core code's job to determine which user mapping OID is relevant, and don't attempt join pushdown unless it's the same for all relevant relations. Per a suggestion from Tom Lane. Shigeru Hanada and Ashutosh Bapat, reviewed by Etsuro Fujita and KaiGai Kohei, with some further changes by me.
-
由 Robert Haas 提交于
This fix accidentally got left out of the previous commit.
-
由 Robert Haas 提交于
Previously, postgres_fdw's connection cache was keyed by user OID and server OID, but this can lead to multiple connections when it's not really necessary. In particular, if all relevant users are mapped to the public user mapping, then their connection options are certainly the same, so one connection can be used for all of them. While we're cleaning things up here, drop the "server" argument to GetConnection(), which isn't really needed. This saves a few cycles because callers no longer have to look this up; the function itself does, but only when establishing a new connection, not when reusing an existing one. Ashutosh Bapat, with a few small changes by me.
-
- 28 1月, 2016 6 次提交
-
-
由 Robert Haas 提交于
Patch-by: Filip Rembiałkowski Reviewed-by: Robert Haas Backpatch-through: 9.5
-
由 Alvaro Herrera 提交于
The documentation mentioned contrib/ but the module was moved to src/test/modules/ by commit 22dfd116 of 9.5 era. Problem pointed out by Dickson Guedes in bug #13896 Backpatch-to: 9.5.
-
由 Fujii Masao 提交于
overriden -> overridden The misspelling in create_extension.sgml was introduced in b67aaf21, so no need to backpatch.
-
由 Fujii Masao 提交于
This function cleans up the pending list of the GIN index by moving entries in it to the main GIN data structure in bulk. It returns the number of pages cleaned up from the pending list. This function is useful, for example, when the pending list needs to be cleaned up *quickly* to improve the performance of the search using GIN index. VACUUM can do the same thing, too, but it may take days to run on a large table. Jeff Janes, reviewed by Julien Rouhaud, Jaime Casanova, Alvaro Herrera and me. Discussion: CAMkU=1x8zFkpfnozXyt40zmR3Ub_kHu58LtRmwHUKRgQss7=iQ@mail.gmail.com
-
由 Robert Haas 提交于
Per off-list discussion with Tom Lane and Michael Paquier, Coverity gets unhappy if this is not done.
-
由 Robert Haas 提交于
Fixes a defect in commit a7de3dc5. David Rowley, per report from Jeff Janes, who also checked that the fix works.
-
- 27 1月, 2016 5 次提交
-
-
由 Fujii Masao 提交于
pg_size_pretty function should be marked immutable rather than volatile because it always returns the same result given the same argument. Pavel Stehule
-
由 Alvaro Herrera 提交于
Previously, it was possible to specify one or several custom scripts to run, or only one of the builtin scripts. With this patch it is also possible to specify to run the builtin scripts multiple times, using the new -b option. Also, unify the code for both cases; this eases future pgbench improvements. Author: Fabien Coelho Review: Michaël Paquier, Álvaro Herrera
-
由 Alvaro Herrera 提交于
pgindent for recent commits; also change some variables from int to boolean, which is how they are really used. Mostly submitted by Fabien Coelho; this is in preparation to commit further patches to the file.
-
由 Tom Lane 提交于
We entirely randomly chose to initialize port->remote_host just after printing the log_connections message, when we could perfectly well do it just before, allowing %h and %r to work for that message. Per gripe from Artem Tomyuk.
-
由 Tom Lane 提交于
The original coding was quite fast so long as objects were always released in reverse order of addition; otherwise, it degenerated into O(N^2) behavior due to searching for the array element to delete. Improve matters by switching to hashed storage when the number of objects of a given type exceeds 64. (The cutover point is open to discussion, of course, but some simple performance testing suggests that hashing has enough overhead to be a loser below there.) Also, refactor resowner.c so that we don't need N copies of the array management code. Since all the resource IDs the code currently needs to deal with are either pointers or integers, it seems sufficient to create a one-size-fits-all infrastructure in which everything is converted to a Datum for storage. Aleksander Alekseev, reviewed by Stas Kelvich, further fixes by me
-
- 26 1月, 2016 2 次提交
-
-
由 Kevin Grittner 提交于
Masahiko Sawada, Fujii Masao, Kevin Grittner
-
由 Tatsuo Ishii 提交于
This reverts commit efc1610b. The commit was plain wrong as pointed out in: http://www.postgresql.org/message-id/27771.1448736909@sss.pgh.pa.us
-
- 25 1月, 2016 2 次提交
-
-
由 Simon Riggs 提交于
We use Share lock because it is safe to do so.
-
由 Tom Lane 提交于
Buildfarm member cockatiel is still saying that cosd(60) isn't 0.5. What seems likely is that the subexpression (1.0 - cos(x)) isn't being rounded to double width before more arithmetic is done on it, so force that by storing it into a variable.
-
- 24 1月, 2016 3 次提交
-
-
由 Tom Lane 提交于
Indeed, the non-static declaration foreseen in my previous commit message is necessary. Per Noah Misch.
-
由 Tom Lane 提交于
The last round didn't do it. Per Noah Misch, the problem on at least some machines is that the compiler pre-evaluates trig functions having constant arguments using code slightly different from what will be used at runtime. Therefore, we must prevent the compiler from seeing constant arguments to any of the libm trig functions used in this code. The method used here might still fail if init_degree_constants() gets inlined into the call sites. That probably won't happen given the large number of call sites; but if it does, we could probably fix it by making init_degree_constants() non-static. I'll avoid that till proven necessary, though.
-
由 Tom Lane 提交于
The buildfarm isn't very happy with the results of commit e1bd684a. To try to get the expected exact results everywhere: * Replace M_PI / 180 subexpressions with a precomputed constant, so that the compiler can't decide to rearrange that division with an adjacent operation. Hopefully this will fix failures to get exactly 0.5 from sind(30) and cosd(60). * Add scaling to ensure that tand(45) and cotd(45) give exactly 1; there was nothing particularly guaranteeing that before. * Replace minus zero by zero when tand() or cotd() would output that; many machines did so for tand(180) and cotd(270), but not all. We could alternatively deem both results valid, but that doesn't seem likely to be what users will want.
-
- 23 1月, 2016 6 次提交
-
-
由 Peter Eisentraut 提交于
Add - ALTER FOREIGN DATA WRAPPER -> RENAME TO - ALTER SERVER -> RENAME TO - ALTER SERVER ... VERSION ... -> OPTIONS - CREATE FOREIGN DATA WRAPPER -> OPTIONS - CREATE SERVER -> OPTIONS - CREATE|ALTER USER MAPPING -> OPTIONS From: Andreas Karlsson <andreas@proxel.se>
-
由 Alvaro Herrera 提交于
The original code was adding double quotes to an already-quoted identifier, leading to nonsensical results. Remove the quoting call. I introduced the broken code in 7eca575d of 9.5 era, so backpatch to 9.5. Report and patch by Elvis Pranskevichus Reviewed by Michael Paquier
-
由 Tom Lane 提交于
The implementations go to some lengths to deliver exact results for values where an exact result can be expected, such as sind(30) = 0.5 exactly. Dean Rasheed, reviewed by Michael Paquier
-
由 Tom Lane 提交于
Ensure that the trig functions return NaN for NaN input regardless of what the underlying C library functions might do. Also ensure that an error is thrown for Inf (or otherwise out-of-range) input, except for atan/atan2 which should accept it. All these behaviors should now conform to the POSIX spec; previously, all our popular platforms deviated from that in one case or another. The main remaining platform dependency here is whether the C library might choose to throw a domain error for sin/cos/tan inputs that are large but less than infinity. (Doing so is not unreasonable, since once a single unit-in-the-last-place exceeds PI, there can be no significance at all in the result; however there doesn't seem to be any suggestion in POSIX that such an error is allowed.) We will report such errors if they are reported via "errno", but not if they are reported via "fetestexcept" which is the other mechanism sanctioned by POSIX. Some preliminary experiments with fetestexcept indicated that it might also report errors we could do without, such as complaining about underflow at an unreasonably large threshold. So let's skip that complexity for now. Dean Rasheed, reviewed by Michael Paquier
-
由 Tom Lane 提交于
Fix chars-vs-bytes confusion here too. Improve poor grammar and markup.
-
由 Tom Lane 提交于
Commit e529cd4f introduced an Assert requiring NAMEDATALEN to be less than MAX_LEVENSHTEIN_STRLEN, which has been 255 for a long time. Since up to that instant we had always allowed NAMEDATALEN to be substantially more than that, this was ill-advised. It's debatable whether we need MAX_LEVENSHTEIN_STRLEN at all (versus putting a CHECK_FOR_INTERRUPTS into the loop), or whether it has to be so tight; but this patch takes the narrower approach of just not applying the MAX_LEVENSHTEIN_STRLEN limit to calls from the parser. Trusting the parser for this seems reasonable, first because the strings are limited to NAMEDATALEN which is unlikely to be hugely more than 256, and second because the maximum distance is tightly constrained by MAX_FUZZY_DISTANCE (though we'd forgotten to make use of that limit in one place). That means the cost is not really O(mn) but more like O(max(m,n)). Relaxing the limit for user-supplied calls is left for future research; given the lack of complaints to date, it doesn't seem very high priority. In passing, fix confusion between lengths-in-bytes and lengths-in-chars in comments and error messages. Per gripe from Kevin Day; solution suggested by Robert Haas. Back-patch to 9.5 where the unwanted restriction was introduced.
-
- 22 1月, 2016 5 次提交
-
-
由 Tom Lane 提交于
Historically, extract() just returned zero for any case involving an infinite timestamp[tz] input; even cases in which the unit name was invalid. This is not very sensible. Instead, return infinity or -infinity as appropriate when the requested field is one that is monotonically increasing (e.g, year, epoch), or NULL when it is not (e.g., day, hour). Also, throw the expected errors for bad unit names. BACKWARDS INCOMPATIBLE CHANGE Vitaly Burovoy, reviewed by Vik Fearing
-
由 Tom Lane 提交于
Given the limited range of i, these shifts should not cause any problem, but that apparently doesn't stop some compilers from whining about them. David Rowley
-
由 Tom Lane 提交于
The amvalidate functions added in commit 65c5fcd3 were on the crude side. Improve them in a few ways: * Perform signature checking for operators and support functions. * Apply more thorough checks for missing operators and functions, where possible. * Instead of reporting problems as ERRORs, report most problems as INFO messages and make the amvalidate function return FALSE. This allows more than one problem to be discovered per run. * Report object names rather than OIDs, and work a bit harder on making the messages understandable. Also, remove a few more opr_sanity regression test queries that are now superseded by the amvalidate checks.
-
由 Tom Lane 提交于
Putting a reference to an expanded-format value into a Const node would be a bad idea for a couple of reasons. It'd be possible for the supposedly immutable Const to change value, if something modified the referenced variable ... in fact, if the Const's reference were R/W, any function that has the Const as argument might itself change it at runtime. Also, because datumIsEqual() is pretty simplistic, the Const might fail to compare equal to other Consts that it should compare equal to, notably including copies of itself. This could lead to unexpected planner behavior, such as "could not find pathkey item to sort" errors or inferior plans. I have not been able to find any way to get an expanded value into a Const within the existing core code; but Paul Ramsey was able to trigger the problem by writing a datatype input function that returns an expanded value. The best fix seems to be to establish a rule that varlena values being placed into Const nodes should be passed through pg_detoast_datum(). That will do nothing (and cost little) in normal cases, but it will flatten expanded values and thereby avoid the above problems. Also, it will convert short-header or compressed values into canonical format, which will avoid possible unexpected lack-of-equality issues for those cases too. And it provides a last-ditch defense against putting a toasted value into a Const, which we already knew was dangerous, cf commit 2b0c86b6. (In the light of this discussion, I'm no longer sure that that commit provided 100% protection against such cases, but this fix should do it.) The test added in commit 65c3d05e to catch datatype input functions with unstable results would fail for functions that returned expanded values; but it seems a bit uncharitable to deem a result unstable just because it's expressed in expanded form, so revise the coding so that we check for bitwise equality only after applying pg_detoast_datum(). That's a sufficient condition anyway given the new rule about detoasting when forming a Const. Back-patch to 9.5 where the expanded-object facility was added. It's possible that this should go back further; but in the absence of clear evidence that there's any live bug in older branches, I'll refrain for now.
-
由 Fujii Masao 提交于
It's an oversight in commit dc943ad9.
-
- 21 1月, 2016 2 次提交
-
-
由 Simon Riggs 提交于
Jeff Janes
-
由 Simon Riggs 提交于
2PC state info is written only to WAL at PREPARE, then read back from WAL at COMMIT PREPARED/ABORT PREPARED. Prepared transactions that live past one bufmgr checkpoint cycle will be written to disk in the same form as previously. Crash recovery path is not altered. Measured performance gains of 50-100% for short 2PC transactions by completely avoiding writing files and fsyncing. Other optimizations still available, further patches in related areas expected. Stas Kelvich and heavily edited by Simon Riggs Based upon earlier ideas and patches by Michael Paquier and Heikki Linnakangas, a concrete example of how Postgres-XC has fed back ideas into PostgreSQL. Reviewed by Michael Paquier, Jeff Janes and Andres Freund Performance testing by Jesper Pedersen
-