aboutsummaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAge
* Tweak wording of syntax error messages about bad CONTINUE/EXIT statements.Tom Lane2015-08-23
| | | | Try to avoid any possible confusion about what these messages mean.
* Reduce number of bytes examined by convert_one_string_to_scalar().Tom Lane2015-08-23
| | | | | | | | | | | | | | | | | | | | | Previously, convert_one_string_to_scalar() would examine up to 20 bytes of the input string, producing a scalar conversion with theoretical precision far greater than is of any possible use considering the other limitations on the accuracy of the resulting selectivity estimate. (I think this choice might pre-date the caller-level logic that strips any common prefix of the strings; before that, there could have been value in scanning the strings far enough to use all the precision available in a double.) Aside from wasting cycles to little purpose, this choice meant that the "denom" variable could grow to as much as 256^21 = 3.74e50, which could overflow in some non-IEEE float arithmetics. While we don't really support any machines with non-IEEE arithmetic anymore, this still seems like quite an unnecessary platform dependency. Limit the scan to 12 bytes instead, thus limiting "denom" to 256^13 = 2.03e31, a value more likely to be computable everywhere. Per testing by Greg Stark, which showed overflow failures in our standard regression tests on VAX.
* Avoid use of float arithmetic in bipartite_match.c.Tom Lane2015-08-23
| | | | | | | | | | | | | | | Since the distances used in this algorithm are small integers (not more than the size of the U set, in fact), there is no good reason to use float arithmetic for them. Use short ints instead: they're smaller, faster, and require no special portability assumptions. Per testing by Greg Stark, which disclosed that the code got into an infinite loop on VAX for lack of IEEE-style float infinities. We don't really care all that much whether Postgres can run on a VAX anymore, but there seems sufficient reason to change this code anyway. In passing, make a few other small adjustments to make the code match usual Postgres coding style a bit better.
* Fix typo in C comment.Kevin Grittner2015-08-23
| | | | | Merlin Moncure Backpatch to 9.5, where the misspelling was introduced
* Improve whitespacePeter Eisentraut2015-08-22
|
* Improve spellingPeter Eisentraut2015-08-22
|
* Add hint to run "pgbench -i", if test tables don't exist.Heikki Linnakangas2015-08-22
| | | | Fabien Coelho, reviewed by Julien Rouhaud
* Avoid O(N^2) behavior when enlarging SPI tuple table in spi_printtup().Tom Lane2015-08-21
| | | | | | | | | | | | | For no obvious reason, spi_printtup() was coded to enlarge the tuple pointer table by just 256 slots at a time, rather than doubling the size at each reallocation, as is our usual habit. For very large SPI results, this makes for O(N^2) time spent in repalloc(), which of course soon comes to dominate the runtime. Use the standard doubling approach instead. This is a longstanding performance bug, so back-patch to all active branches. Neil Conway
* Detect mismatched CONTINUE and EXIT statements at plpgsql compile time.Tom Lane2015-08-21
| | | | | | | | | | | With a bit of tweaking of the compile namestack data structure, we can verify at compile time whether a CONTINUE or EXIT is legal. This is surely better than leaving it to runtime, both because earlier is better and because we can issue a proper error pointer. Also, we can get rid of the ad-hoc old way of detecting the problem, which only took care of CONTINUE not EXIT. Jim Nasby, adjusted a bit by me
* Clean up roles from roleattributes testStephen Frost2015-08-21
| | | | | | Having the roles remain after the test ends up causing repeated 'make installcheck' runs to fail and may be risky from a security perspective also, so remove them at the end of the test.
* Do not allow *timestamp to be passed as NULLAlvaro Herrera2015-08-21
| | | | | | | | | | | | | The code had bugs that would cause crashes if NULL was passed as that argument (originally intended to mean not to bother returning its value), and after inspection it turns out that nothing seems interested in the case that *ts is NULL anyway. Therefore, remove the partial checks intended to support that case. Author: Michael Paquier though I didn't include a proposed Assert. Backpatch to 9.5.
* Remove ExecGetScanType functionAlvaro Herrera2015-08-21
| | | | This became unused in a191a169d6d0b9558da4519e66510c4540204a51.
* Fix plpython crash when returning string representation of a RECORD result.Tom Lane2015-08-21
| | | | | | | | | | | | | | | | | | | | | | | | | | | PLyString_ToComposite() blithely overwrote proc->result.out.d, even though for a composite result type the other union variant proc->result.out.r is the one that should be valid. This could result in a crash if out.r had in fact been filled in (proc->result.is_rowtype == 1) and then somebody later attempted to use that data; as per bug #13579 from Paweł Michalak. Just to add insult to injury, it didn't work for RECORD results anyway, because record_in() would refuse the case. Fix by doing the I/O function lookup in a local PLyTypeInfo variable, as we were doing already in PLyObject_ToComposite(). This is not a great technique because any fn_extra data allocated by the input function will be leaked permanently (thanks to using TopMemoryContext as fn_mcxt). But that's a pre-existing issue that is much less serious than a crash, so leave it to be fixed separately. This bug would be a potential security issue, except that plpython is only available to superusers and the crash requires coding the function in a way that didn't work before today's patches. Add regression test cases covering all the supported methods of converting composite results. Back-patch to 9.1 where the faulty coding was introduced.
* Allow record_in() and record_recv() to work for transient record types.Tom Lane2015-08-21
| | | | | | | | | | | | | | | | | | If we have the typmod that identifies a registered record type, there's no reason that record_in() should refuse to perform input conversion for it. Now, in direct SQL usage, record_in() will always be passed typmod = -1 with type OID RECORDOID, because no typmodin exists for type RECORD, so the case can't arise. However, some InputFunctionCall users such as PLs may be able to supply the right typmod, so we should allow this to support them. Note: the previous coding and comment here predate commit 59c016aa9f490b53. There has been no case since 8.1 in which the passed type OID wouldn't be valid; and if it weren't, this error message wouldn't be apropos anyway. Better to let lookup_rowtype_tupdesc complain about it. Back-patch to 9.1, as this is necessary for my upcoming plpython fix. I'm committing it separately just to make it a bit more visible in the commit history.
* Rename 'cmd' to 'cmd_name' in CreatePolicyStmtStephen Frost2015-08-21
| | | | | | | | | | | To avoid confusion, rename CreatePolicyStmt's 'cmd' to 'cmd_name', parse_policy_command's 'cmd' to 'polcmd', and AlterPolicy's 'cmd_datum' to 'polcmd_datum', per discussion with Noah and as a follow-up to his correction of copynodes/equalnodes handling of the CreatePolicyStmt 'cmd' field. Back-patch to 9.5 where the CreatePolicyStmt was introduced, as we are still only in alpha.
* In AlterRole, make bypassrls an intStephen Frost2015-08-21
| | | | | | | | | | | | | | | | When reworking bypassrls in AlterRole to operate the same way the other attribute handling is done, I missed that the variable was incorrectly a bool rather than an int. This meant that on platforms with an unsigned char, we could end up with incorrect behavior during ALTER ROLE. Pointed out by Andres thanks to tests he did changing our bool to be the one from stdbool.h which showed this and a number of other issues. Add regression tests to test CREATE/ALTER role for the various role attributes. Arrange to leave roles behind for testing pg_dumpall, but none which have the LOGIN attribute. Back-patch to 9.5 where the AlterRole bug exists.
* doc: Whitespace and formatting fixesPeter Eisentraut2015-08-20
|
* Remove xpath namespace-handling change from 9.5 release notes.Tom Lane2015-08-20
| | | | | | Although commit 79af9a1d2 was initially applied to HEAD only, we later back-patched the change into all branches (commits 6bbf75192 et al). So it's not a new behavior in 9.5 and should not be release-noted here.
* Update config.guess and config.subPeter Eisentraut2015-08-19
|
* Fix bug in calculations of hash join buckets.Kevin Grittner2015-08-19
| | | | | | | | | | | | | | Commit 8cce08f168481c5fc5be4e7e29b968e314f1b41e used a left-shift on a literal of 1 that could (in large allocations) be shifted by 31 or more bits. This was assigned to a local variable that was already declared to be a long to protect against overruns of int, but the literal in this shift needs to be declared long to allow it to work correctly in some compilers. Backpatch to 9.5, where the bug was introduced. Report and patch by KaiGai Kohei, slighly modified based on discussion.
* Fix a few bogus statement type names in plpgsql error messages.Tom Lane2015-08-18
| | | | | | | | | | | | | | | | | | plpgsql's error location context messages ("PL/pgSQL function fn-name line line-no at stmt-type") would misreport a CONTINUE statement as being an EXIT, and misreport a MOVE statement as being a FETCH. These are clear bugs that have been there a long time, so back-patch to all supported branches. In addition, in 9.5 and HEAD, change the description of EXECUTE from "EXECUTE statement" to just plain EXECUTE; there seems no good reason why this statement type should be described differently from others that have a well-defined head keyword. And distinguish GET STACKED DIAGNOSTICS from plain GET DIAGNOSTICS. These are a bit more of a judgment call, and also affect existing regression-test outputs, so I did not back-patch into stable branches. Pavel Stehule and Tom Lane
* psql: Make EXECUTE PROCEDURE tab completion a bit narrower.Robert Haas2015-08-18
| | | | | | | If the user has typed GRANT EXECUTE, the correct completion is "ON", not "PROCEDURE". Daniel Verite
* Fix performance bug from conflict between two previous improvements.Tom Lane2015-08-17
| | | | | | | | | | | | | | | | | My expanded-objects patch (commit 1dc5ebc9077ab742) included code to make plpgsql pass expanded-object variables as R/W pointers to certain functions that are trusted for modifying such variables in-place. However, that optimization got broken by commit 6c82d8d1fdb1f126, which arranged to share a single ParamListInfo across most expressions evaluated by a plpgsql function. We don't want a R/W pointer to be passed to other functions just because we decided one function was safe! Fortunately, the breakage was in the other direction, of never passing a R/W pointer at all, because we'd always have pre-initialized the shared array slot with a R/O pointer. So it was still functionally correct, but we were back to O(N^2) performance for repeated use of "a := a || x". To fix, force an unshared param array to be used when the R/W param optimization is active. Commit 6c82d8d1fdb1f126 is in HEAD only, so no need for a back-patch.
* docs: Fix "typo" introduced in 3f811c2d.Andres Freund2015-08-17
| | | | | Reported-By: Michael Paquier Discussion: CAB7nPqSco+RFw9C-VgbCpyurQB3OocS-fuTOa_gFnUy1EE-pyQ@mail.gmail.com
* Improve configure test for the sse4.2 crc instruction.Andres Freund2015-08-17
| | | | | | | | | | | | | | | | With optimizations enabled at least one compiler, clang 3.7, optimized away the crc intrinsics knowing that the result went on unused and has no side effects. That can trigger errors in code generation when the intrinsic is used, as we chose to use the intrinsics without any additional compiler flag. Return the computed value to prevent that. With some more pedantic warning flags (-Wold-style-definition) the configure test failed to recognize the existence of _mm_crc32_u* intrinsics due to an independent warning in the test because the test turned on -Werror, but that's not actually needed here. Discussion: 20150814092039.GH4955@awork2.anarazel.de Backpatch: 9.5, where the use of crc intrinsics was integrated.
* Fix reporting of skipped transactions in pgbench.Heikki Linnakangas2015-08-17
| | | | | | Broken by commit 1bc90f7a. Fabien Coelho.
* Add docs about postgres_fdw's setting of search_path and other GUCs.Tom Lane2015-08-15
| | | | | | | | This behavior wasn't documented, but it should be because it's user-visible in triggers and other functions executed on the remote server. Per question from Adam Fuchs. Back-patch to 9.3 where postgres_fdw was added.
* Improve documentation about MVCC-unsafe utility commands.Tom Lane2015-08-15
| | | | | | | | | | | | | | | | | | | The table-rewriting forms of ALTER TABLE are MVCC-unsafe, in much the same way as TRUNCATE, because they replace all rows of the table with newly-made rows with a new xmin. (Ideally, concurrent transactions with old snapshots would continue to see the old table contents, but the data is not there anymore --- and if it were there, it would be inconsistent with the table's updated rowtype, so there would be serious implementation problems to fix.) This was nowhere documented though, and the problem was only documented for TRUNCATE in a note in the TRUNCATE reference page. Create a new "Caveats" section in the MVCC chapter that can be home to this and other limitations on serializable consistency. In passing, fix a mistaken statement that VACUUM and CLUSTER would reclaim space occupied by a dropped column. They don't reconstruct existing tuples so they couldn't do that. Back-patch to all supported branches.
* Repair unsafe use of shared typecast-lookup table in plpgsql DO blocks.Tom Lane2015-08-15
| | | | | | | | | | | | | | | | DO blocks use private simple_eval_estates to avoid intra-transaction memory leakage, cf commit c7b849a89. I had forgotten about that while writing commit 0fc94a5ba, but it means that expression execution trees created within a DO block disappear immediately on exiting the DO block, and hence can't safely be linked into plpgsql's session-wide cast hash table. To fix, give a DO block a private cast hash table to go with its private simple_eval_estate. This is less efficient than one could wish, since DO blocks can no longer share any cast lookup work with other plpgsql execution, but it shouldn't be too bad; in any case it's no worse than what happened in DO blocks before commit 0fc94a5ba. Per bug #13571 from Feike Steenbergen. Preliminary analysis by Oleksandr Shulgin.
* Don't use function definitions looking like old-style ones.Andres Freund2015-08-15
| | | | | | | This fixes a bunch of somewhat pedantic warnings with new compilers. Since by far the majority of other functions definitions use the (void) style it just seems to be consistent to do so as well in the remaining few places.
* Correct type of waitMode variable in ExecInsertIndexTuples().Andres Freund2015-08-15
| | | | | | | | | It was a bool, even though it should be CEOUC_WAIT_MODE. That's unlikely to have a negative effect with the current definition of bool (char), but it's definitely wrong. Discussion: 20150812084351.GD8470@awork2.anarazel.de Backpatch: 9.5, where ON CONFLICT was merged
* vacuumdb: Don't assign negative values to a boolean.Andres Freund2015-08-15
| | | | | | | | | | Since a17923204736 (vacuumdb: enable parallel mode) -1 has been assigned to a boolean. That can, justifiedly, trigger compiler warnings. There's also no need for ternary logic, result was only ever set to 0 or -1. So don't. Discussion: 20150812084351.GD8470@awork2.anarazel.de Backpatch: 9.5
* Don't use 'bool' as a struct member name in help_config.c.Andres Freund2015-08-15
| | | | | | | | | | | | Doing so doesn't work if bool is a macro rather than a typedef. Although c.h spends some effort to support configurations where bool is a preexisting macro, help_config.c has existed this way since 2003 (b700a6), and there have not been any reports of problems. Backpatch anyway since this is as riskless as it gets. Discussion: 20150812084351.GD8470@awork2.anarazel.de Backpatch: 9.0-master
* Use the correct type for TableInfo->relreplident.Andres Freund2015-08-15
| | | | | | | | Mistakenly relreplident was stored as a bool. That works today as c.h typedefs bool to a char, but isn't very future proof. Discussion: 20150812084351.GD8470@awork2.anarazel.de Backpatch: 9.4 where replica identity was introduced.
* Remove unused expected-output file.Robert Haas2015-08-14
|
* Remove bogus step from test_decoding isolation tests.Robert Haas2015-08-14
| | | | | | | | | | Commit 43b4a16817c8b5568cec72f3b0e1c8209f5ac7f7 made the isolation tester reject duplicate step names, and it turns out that the test_decoding module's concurrent_ddl_dml isolation test has a duplicate name. I think the second definition isn't actually getting used, so just remove it. Per buildfarm.
* Reject isolation test specifications with duplicate step names.Robert Haas2015-08-14
| | | | | alter-table-1.spec has such a case, so change one instance of step rx1 to rx3 instead.
* Encoding PG_UHC is code page 949.Noah Misch2015-08-14
| | | | | | | | | | | This fixes presentation of non-ASCII messages to the Windows event log and console in rare cases involving Korean locale. Processes like the postmaster and checkpointer, but not processes attached to databases, were affected. Back-patch to 9.4, where MessageEncoding was introduced. The problem exists in all supported versions, but this change has no effect in the absence of the code recognizing PG_UHC MessageEncoding. Noticed while investigating bug #13427 from Dmitri Bourlatchkov.
* Restore old pgwin32_message_to_UTF16() behavior outside transactions.Noah Misch2015-08-14
| | | | | | | | | | | Commit 49c817eab78c6f0ce8c3bf46766b73d6cf3190b7 replaced with a hard error the dubious pg_do_encoding_conversion() behavior when outside a transaction. Reintroduce the historic soft failure locally within pgwin32_message_to_UTF16(). This fixes errors when writing messages in less-common encodings to the Windows event log or console. Back-patch to 9.4, where the aforementioned commit first appeared. Per bug #13427 from Dmitri Bourlatchkov.
* Update key words table for 9.5Peter Eisentraut2015-08-14
|
* Reduce lock levels for ALTER TABLE SET autovacuum storage optionsSimon Riggs2015-08-14
| | | | | | | | | | | | Reduce lock levels down to ShareUpdateExclusiveLock for all autovacuum-related relation options when setting them using ALTER TABLE. Add infrastructure to allow varying lock levels for relation options in later patches. Setting multiple options together uses the highest lock level required for any option. Works for both main and toast tables. Fabrízio Mello, reviewed by Michael Paquier, mild edit and additional regression tests from myself
* PL/Python: Make tests pass with Python 3.5Peter Eisentraut2015-08-13
| | | | | | | | | The error message wording for AttributeError has changed in Python 3.5. For the plpython_error test, add a new expected file. In the plpython_subtransaction test, we didn't really care what the exception is, only that it is something coming from Python. So use a generic exception instead, which has a message that doesn't vary across versions.
* MSVC: Exclude 'brin' contrib moduleAlvaro Herrera2015-08-13
| | | | The build script is not able to parse the Makefile, so remove it.
* Re-add BRIN isolation testAlvaro Herrera2015-08-13
| | | | | | | | | | | | This time, instead of using a core isolation test, put it on its own test module; this way it can require the pageinspect module to be present before running. The module's Makefile is loosely modeled after test_decoding's, so that it's easy to add further tests for either pg_regress or isolationtester later. Backpatch to 9.5.
* Improve regression test case to avoid depending on system catalog stats.Tom Lane2015-08-13
| | | | | | | | | | | | | | | | | | | | | | | In commit 95f4e59c32866716 I added a regression test case that examined the plan of a query on system catalogs. That isn't a terribly great idea because the catalogs tend to change from version to version, or even within a version if someone makes an unrelated regression-test change that populates the catalogs a bit differently. Usually I try to make planner test cases rely on test tables that have not changed since Berkeley days, but I got sloppy in this case because the submitted crasher example queried the catalogs and I didn't spend enough time on rewriting it. But it was a problem waiting to happen, as I was rudely reminded when I tried to port that patch into Salesforce's Postgres variant :-(. So spend a little more effort and rewrite the query to not use any system catalogs. I verified that this version still provokes the Assert if 95f4e59c32866716's code fix is reverted. I also removed the EXPLAIN output from the test, as it turns out that the assertion occurs while considering a plan that isn't the one ultimately selected anyway; so there's no value in risking any cross-platform variation in that printout. Back-patch to 9.2, like the previous patch.
* Use materialize SRF mode in brin_page_itemsAlvaro Herrera2015-08-13
| | | | | | | | | This function was using the single-value-per-call mechanism, but the code relied on a relcache entry that wasn't kept open across calls. This manifested as weird errors in buildfarm during the short time that the "brin-1" isolation test lived. Backpatch to 9.5, where it was introduced.
* Run autoheader to add a few missing #defines to pg_config.h.in.Heikki Linnakangas2015-08-13
| | | | | | | | These are emitted by the new ax_pthread.m4 script version. They are not used for anything in PostgreSQL, but let's keep the generated header file up-to-date. Andres Freund
* Fix declaration of isarray variable.Michael Meskes2015-08-13
| | | | Found and fixed by Andres Freund.
* Fix unitialized variablesAlvaro Herrera2015-08-13
| | | | | | | | | As complained by clang, reported by Andres Freund. Brown paper bag bug in ccc4c074994d. Add some comments, too. Backpatch to 9.5, like that one.
* Undo mistaken tightening in join_is_legal().Tom Lane2015-08-12
| | | | | | | | | | | | | | | | | | | One of the changes I made in commit 8703059c6b55c427 turns out not to have been such a good idea: we still need the exception in join_is_legal() that allows a join if both inputs already overlap the RHS of the special join we're checking. Otherwise we can miss valid plans, and might indeed fail to find a plan at all, as in recent report from Andreas Seltenreich. That code was added way back in commit c17117649b9ae23d, but I failed to include a regression test case then; my bad. Put it back with a better explanation, and a test this time. The logic does end up a bit different than before though: I now believe it's appropriate to make this check first, thereby allowing such a case whether or not we'd consider the previous SJ(s) to commute with this one. (Presumably, we already decided they did; but it was confusing to have this consideration in the middle of the code that was handling the other case.) Back-patch to all active branches, like the previous patch.
generated by cgit v1.2.3 (git 2.25.1) at 2025-08-05 09:09:01 +0000