aboutsummaryrefslogtreecommitdiff
path: root/src
Commit message (Collapse)AuthorAge
...
* Remove unnecessary AssertMacro() to suppress gcc 4.6 compiler warning.Tom Lane2011-10-18
| | | | | | | | | | There's no particular value in doing AssertMacro((tup) != NULL) in front of code that's certain to crash anyway if tup is NULL. And if "tup" is actually the address of a local variable, gcc 4.6 whinges about it. That's arguably pretty broken on gcc's part, but we might as well remove the useless test to silence the warnings. This gets rid of all the -Waddress warnings in the backend; there are some in libpq and psql that are a bit harder to avoid.
* Fix pg_dump to dump casts between auto-generated types.Tom Lane2011-10-18
| | | | | | | | | | | | | | The heuristic for when to dump a cast failed for a cast between table rowtypes, as reported by Frédéric Rejol. Fix it by setting the "dump" flag for such a type the same way as the flag is set for the underlying table or base type. This won't result in the auto-generated type appearing in the output, since setting its objType to DO_DUMMY_TYPE unconditionally suppresses that. But it will result in dumpCast doing what was intended. Back-patch to 8.3. The 8.2 code is rather different in this area, and it doesn't seem worth any risk to fix a corner case that nobody has stumbled on before.
* Exclude postmaster.opts from base backupsMagnus Hagander2011-10-18
| | | | Noted by Fujii Masao
* Avoid assuming that index-only scan data matches the index's rowtype.Tom Lane2011-10-16
| | | | | | | | | | | | | | | | | | | | | | In general the data returned by an index-only scan should have the datatypes originally computed by FormIndexDatum. If the index opclasses use "storage" datatypes different from their input datatypes, the scan tuple will not have the same rowtype attributed to the index; but we had a hard-wired assumption that that was true in nodeIndexonlyscan.c. We'd already hacked around the issue for the one case where the types are different in btree indexes (btree name_ops), but this would definitely come back to bite us if we ever implement index-only scans in GiST. To fix, require the index AM to explicitly provide the tupdesc for the tuple it is returning. btree can just pass back the index's tupdesc, but GiST will have to work harder when and if it supports index-only scans. I had previously proposed fixing this by allowing the index AM to fill the scan tuple slot directly; but on reflection that seemed like a module layering violation, since TupleTableSlots are creatures of the executor. At least in the btree case, it would also be less efficient, since the tuple deconstruction work would occur even for rows later found to be invisible to the scan's snapshot.
* Fix collate.linux.utf8 expected output for recent error message change.Tom Lane2011-10-16
| | | | Noted by Jeff Davis.
* Teach btree to handle ScalarArrayOpExpr quals natively.Tom Lane2011-10-16
| | | | | This allows "indexedcol op ANY(ARRAY[...])" conditions to be used in plain indexscans, and particularly in index-only scans.
* Allow a major PG version psql .psqlrc file to be used if a minorBruce Momjian2011-10-14
| | | | | matching version file does not exist. This avoids needing to rename .psqlrc files after minor version upgrades.
* Fix bugs in information_schema.referential_constraints view.Tom Lane2011-10-14
| | | | | | | | | | | | | | | | This view was being insufficiently careful about matching the FK constraint to the depended-on primary or unique key constraint. That could result in failure to show an FK constraint at all, or showing it multiple times, or claiming that it depended on a different constraint than the one it really does. Fix by joining via pg_depend to ensure that we find only the correct dependency. Back-patch, but don't bump catversion because we can't force initdb in back branches. The next minor-version release notes should explain that if you need to fix this in an existing installation, you can drop the information_schema schema then re-create it by sourcing $SHAREDIR/information_schema.sql in each database (as a superuser of course).
* Measure the number of all-visible pages for use in index-only scan costing.Tom Lane2011-10-14
| | | | | | | | | | | | | | | | | Add a column pg_class.relallvisible to remember the number of pages that were all-visible according to the visibility map as of the last VACUUM (or ANALYZE, or some other operations that update pg_class.relpages). Use relallvisible/relpages, instead of an arbitrary constant, to estimate how many heap page fetches can be avoided during an index-only scan. This is pretty primitive and will no doubt see refinements once we've acquired more field experience with the index-only scan mechanism, but it's way better than using a constant. Note: I had to adjust an underspecified query in the window.sql regression test, because it was changing answers when the plan changed to use an index-only scan. Some of the adjacent tests perhaps should be adjusted as well, but I didn't do that here.
* Dump all roles first, then all config settings on roles.Robert Haas2011-10-14
| | | | | | | | This way, if a role's config setting uses the name of another role, the validity of the dump isn't dependent on the order in which those two roles are dumped. Code by Phil Sorber, comment by me.
* Avoid potential relcache leak in objectaddress.c.Robert Haas2011-10-14
| | | | | | | Nobody using the missing_ok flag yet, but let's speculate that this will be a better interface for future callers. KaiGai Kohei, with some adjustments by me.
* Remove all "traces" of trace_userlocks, because userlocks were removedBruce Momjian2011-10-13
| | | | in PG 8.2.
* Fix up Perl-to-Postgres datatype conversions in pl/perl.Tom Lane2011-10-13
| | | | | | | | | | | | | | | | | | | | | | | | | | This patch restores the pre-9.1 behavior that pl/perl functions returning VOID ignore the result value of their last Perl statement. 9.1.0 unintentionally threw an error if the last statement returned a reference, as reported by Amit Khandekar. Also, make sure it works to return a string value for a composite type, so long as the string meets the type's input format. We already allowed the equivalent behavior for arrays, so it seems inconsistent to not allow it for composites. In addition, ensure we throw errors for attempts to return arrays or hashes when the function's declared result type is not an array or composite type, respectively. Pre-9.1 versions rather uselessly returned strings like ARRAY(0x221a9a0) or HASH(0x221aa90), while 9.1.0 threw an error for the hash case and returned a garbage value for the array case. Also, clean up assorted grotty coding in Perl array conversion, including use of a session-lifespan memory context to accumulate the array value (resulting in session-lifespan memory leak on error), failure to apply the declared typmod if any, and failure to detect some cases of non-rectangular multi-dimensional arrays. Alex Hunsaker and Tom Lane
* Have pg_ctl return an exit status of 3 if the server is not running, toBruce Momjian2011-10-13
| | | | | | match the Linux Standard Base Core Specification 3.1. Aaron W. Swenson
* Don't mark auto-generated types as extension members.Tom Lane2011-10-12
| | | | | | | | | | | | | | | | | | Relation rowtypes and automatically-generated array types do not need to have their own extension membership dependency entries. If we create such then it becomes more difficult to remove items from an extension, and it's also harder for an extension upgrade script to make sure it duplicates the dependencies created by the extension's regular installation script. I changed the code in such a way that this happened in commit 988cccc620dd8c16d77f88ede167b22056176324, I think because of worries about the shell-type-replacement case; but that cure was worse than the disease. It would only matter if one extension created a shell type that was replaced with an auto-generated type in another extension, which seems pretty far-fetched. Better to make this work unsurprisingly in normal cases. Report and patch by Robert Haas, comment adjustments by me.
* Modify RelationGetBufferForTuple() to use a typedef, rather than aBruce Momjian2011-10-12
| | | | struct, to help pgindent.
* Modify pgindent to use a renamed pg_bsd_indent binary. New featuresBruce Momjian2011-10-12
| | | | | include the ability to supply a typedef file, rather than list them on the command line. Also improve the README.
* Throw a useful error message if an extension script file is fed to psql.Tom Lane2011-10-12
| | | | | | | | | | | | | | | | We have seen one too many reports of people trying to use 9.1 extension files in the old-fashioned way of sourcing them in psql. Not only does that usually not work (due to failure to substitute for MODULE_PATHNAME and/or @extschema@), but if it did work they'd get a collection of loose objects not an extension. To prevent this, insert an \echo ... \quit line that prints a suitable error message into each extension script file, and teach commands/extension.c to ignore lines starting with \echo. That should not only prevent any adverse consequences of loading a script file the wrong way, but make it crystal clear to users that they need to do it differently now. Tom Lane, following an idea of Andrew Dunstan's. Back-patch into 9.1 ... there is not going to be much value in this if we wait till 9.2.
* Add comment on why pulling data from a "name" index column can't crash.Tom Lane2011-10-11
| | | | | | | | | | | It's been bothering me for several days that pretending that the cstring data stored in a btree name_ops column is really a "name" Datum could lead to reading past the end of memory. However, given the current memory layout used for index-only scans in the btree code, a crash is in fact not possible. Document that so we don't break it. I have not thought of any other solutions that aren't fairly ugly too, and most of them lose the functionality of index-only scans on name columns altogether, so this seems like the way to go.
* Generate index-only scan tuple descriptor from the plan node's indextlist.Tom Lane2011-10-11
| | | | | | | | | | Dept. of second thoughts: as long as we've got that tlist hanging around anyway, we can apply ExecTypeFromTL to it to get a suitable descriptor for the ScanTupleSlot. This is a nicer solution than the previous one because it eliminates some hard-wired knowledge about btree name_ops, and because it avoids the somewhat shaky assumption that we needn't set up the scan tuple descriptor in EXPLAIN_ONLY mode. It doesn't change what actually happens at run-time though, and I'm still a bit nervous about that.
* Improve entab's Makefile install entry.Bruce Momjian2011-10-11
| | | | Andrew Dunstan
* Consider index-only scans even when there is no matching qual or ORDER BY.Tom Lane2011-10-11
| | | | By popular demand.
* Rearrange the implementation of index-only scans.Tom Lane2011-10-11
| | | | | | | | | | | | | | | | | | | | | | This commit changes index-only scans so that data is read directly from the index tuple without first generating a faux heap tuple. The only immediate benefit is that indexes on system columns (such as OID) can be used in index-only scans, but this is necessary infrastructure if we are ever to support index-only scans on expression indexes. The executor is now ready for that, though the planner still needs substantial work to recognize the possibility. To do this, Vars in index-only plan nodes have to refer to index columns not heap columns. I introduced a new special varno, INDEX_VAR, to mark such Vars to avoid confusion. (In passing, this commit renames the two existing special varnos to OUTER_VAR and INNER_VAR.) This allows ruleutils.c to handle them with logic similar to what we use for subplan reference Vars. Since index-only scans are now fundamentally different from regular indexscans so far as their expression subtrees are concerned, I also chose to change them to have their own plan node type (and hence, their own executor source file).
* Replace hardcoded switch in object_exists() with a lookup table.Robert Haas2011-10-11
| | | | | | | | | | | | There's no particular advantage to this change on its face; indeed, it's possible that this might be slightly slower than the old way. But it makes this information more easily accessible to other functions, and therefore paves the way for future code consolidation. Performance isn't critical here, so there's no need to be smart about how we do the search. This is a heavily cut-down version of a patch from KaiGai Kohei, with several fixes by me. Additional review from Dimitri Fontaine.
* Repair breakage in VirtualXactLock.Robert Haas2011-10-11
| | | | | I broke this in commit 84e37126770dd6de903dad88ce150a49b63b5ef9. Report and fix by Fujii Masao.
* Mark GUC external_pid_file's default as '' in postgresql.conf, ratherBruce Momjian2011-10-10
| | | | than '(none)'.
* Attempt to reduce local dependencies in regression tests.Robert Haas2011-10-10
| | | | | | | This appears to be another case where the relative sort order of letters vs. numbers can throw things off. Pavel Stehule
* Fix ALTER TABLE ONLY .. DROP CONSTRAINT.Robert Haas2011-10-09
| | | | | | | | | | | | | | | | | | When I consolidated two copies of the HOT-chain search logic in commit 4da99ea4231e3d8bbf28b666748c1028e7b7d665, I introduced a behavior change: the old code wouldn't necessarily traverse the entire chain, if the most recently returned tuple were updated while the HOT chain traversal is in progress. The new behavior seems more correct, but unfortunately, the code here relies on a scan with SnapshotNow failing to see its own updates. That seems pretty shaky even with the old HOT chain traversal behavior, since there's no guarantee that these updates will always be HOT, but it's trivial to broke a failure with the new HOT search logic. Fix by updating just the first matching pg_constraint tuple, rather than all of them, since there should be only one anyway. But since nobody has reproduced this failure on older versions, no back-patch for now. Report and test case by Alex Hunsaker; tablecmds.c changes by me.
* Revert accidental change to pg_config_manual.h.Robert Haas2011-10-09
| | | | | | | | | This was broken in commit 53dbc27c62d8e1b6c5253feba04a5094cb8fe046, which introduced unlogged tables. Fortunately, as debugging tools go, this one is pretty cheap, which is probably why it took nine months for someone to notice, but it's not intended to be enabled by default, so revert. Noted by Fujii Masao.
* Clean up a couple of box gist helper functions.Heikki Linnakangas2011-10-09
| | | | | | | | | | The original idea of this patch was to make box picksplit run faster, by eliminating unnecessary palloc() overhead, but that was obsoleted by the new double-sorting split algorithm that doesn't call these functions so heavily anymore. Nevertheless, the code looks better this way. Original patch by me, reviewed and tidied up after the double-sorting patch by Kevin Grittner.
* Improve index-only scans to avoid repeated access to the index page.Tom Lane2011-10-09
| | | | | | | | | | | | We copy all the matched tuples off the page during _bt_readpage, instead of expensively re-locking the page during each subsequent tuple fetch. This costs a bit more local storage, but not more than 2*BLCKSZ worth, and the reduction in LWLock traffic is certainly worth that. What's more, this lets us get rid of the API wart in the original patch that said an index AM could randomly decline to supply an index tuple despite having asserted pg_am.amcanreturn. That will be important for future improvements in the index-only-scan feature, since the executor will now be able to rely on having the index data available.
* Prevent index-only scans in stats regression test.Tom Lane2011-10-08
| | | | | | | | | This bollixes the test because it's expecting to see the idx_tup_fetch counter increase, which won't happen if heap fetches were avoided by use of an index-only scan. Per buildfarm results. While at it, let's just make sure that enable_seqscan and enable_indexscan are ON for this test ...
* Fix brain fade in cost estimation for index-only scans.Tom Lane2011-10-08
| | | | | visibility_fraction should not be applied to regular indexscans. Noted by Cédric Villemain.
* Don't let transform_null_equals=on affect CASE foo WHEN NULL ... constructs.Heikki Linnakangas2011-10-08
| | | | | | | | | transform_null_equals is only supposed to affect "foo = NULL" expressions given directly by the user, not the internal "foo = NULL" expression generated from CASE-WHEN. This fixes bug #6242, reported by Sergey. Backpatch to all supported branches.
* Fix typo.Heikki Linnakangas2011-10-08
|
* Try to fix memory barriers on x86_64.Robert Haas2011-10-07
| | | | %esp is no good; must use %rsp there.
* Support index-only scans using the visibility map to avoid heap fetches.Tom Lane2011-10-07
| | | | | | | | | | | | | When a btree index contains all columns required by the query, and the visibility map shows that all tuples on a target heap page are visible-to-all, we don't need to fetch that heap page. This patch depends on the previous patches that made the visibility map reliable. There's a fair amount left to do here, notably trying to figure out a less chintzy way of estimating the cost of an index-only scan, but the core functionality seems ready to commit. Robert Haas and Ibrar Ahmed, with some previous work by Heikki Linnakangas.
* Ensure walsenders can be SIGTERMed while in non-walsender codeMagnus Hagander2011-10-06
| | | | | | | In oder to exit on SIGTERM when in non-walsender code, such as do_pg_stop_backup(), we need to set the interrupt variables that are used there, and not just the walsender local ones.
* Simplify new pg_ctl newline termination code.Bruce Momjian2011-10-06
|
* Add postmaster -C option to query configuration parameters, and haveBruce Momjian2011-10-06
| | | | | | pg_ctl use that to query the data directory for config-only installs. This fixes awkward or impossible pg_ctl operation for config-only installs.
* Replace the "New Linear" GiST split algorithm for boxes and points with aHeikki Linnakangas2011-10-06
| | | | | | | new double-sorting algorithm. The new algorithm produces better quality trees, making searches faster. Alexander Korotkov
* Improve and simplify CREATE EXTENSION's management of GUC variables.Tom Lane2011-10-05
| | | | | | | | | | | | | | | | | | | | | CREATE EXTENSION needs to transiently set search_path, as well as client_min_messages and log_min_messages. We were doing this by the expedient of saving the current string value of each variable, doing a SET LOCAL, and then doing another SET LOCAL with the previous value at the end of the command. This is a bit expensive though, and it also fails badly if there is anything funny about the existing search_path value, as seen in a recent report from Roger Niederland. Fortunately, there's a much better way, which is to piggyback on the GUC infrastructure previously developed for functions with SET options. We just open a new GUC nesting level, do our assignments with GUC_ACTION_SAVE, and then close the nesting level when done. This automatically restores the prior settings without a re-parsing pass, so (in principle anyway) there can't be an error. And guc.c still takes care of cleanup in event of an error abort. The CREATE EXTENSION code for this was modeled on some much older code in ri_triggers.c, which I also changed to use the better method, even though there wasn't really much risk of failure there. Also improve the comments in guc.c to reflect this additional usage.
* Improve define_custom_variable's handling of pre-existing settings.Tom Lane2011-10-04
| | | | | | | | | | | | | | | | Arrange for any problems with pre-existing settings to be reported as WARNING not ERROR, so that we don't undesirably abort the loading of the incoming add-on module. The bad setting is just discarded, as though it had never been applied at all. (This requires a change in the API of set_config_option. After some thought I decided the most potentially useful addition was to allow callers to just pass in a desired elevel.) Arrange to restore the complete stacked state of the variable, rather than cheesily reinstalling only the active value. This ensures that custom GUCs will behave unsurprisingly even when the module loading operation occurs within nested subtransactions that have changed the active value. Since a module load could occur as a result of, eg, a PL function call, this is not an unlikely scenario.
* Fix uninitialized-variable bug.Tom Lane2011-10-04
|
* Add sourcefile/sourceline data to EXEC_BACKEND GUC transmission files.Tom Lane2011-10-04
| | | | | | | | | | This oversight meant that on Windows, the pg_settings view would not display source file or line number information for values coming from postgresql.conf, unless the backend had received a SIGHUP since starting. In passing, also make the error detection in read_nondefault_variables a tad more thorough, and fix it to not lose precision on float GUCs (these changes are already in HEAD as of my previous commit).
* Remember the source GucContext for each GUC parameter.Tom Lane2011-10-04
| | | | | | | | | | | | We used to just remember the GucSource, but saving GucContext too provides a little more information --- notably, whether a SET was done by a superuser or regular user. This allows us to rip out the fairly dodgy code that define_custom_variable used to use to try to infer the context to re-install a pre-existing setting with. In particular, it now works for a superuser to SET a extension's SUSET custom variable before loading the associated extension, because GUC can remember whether the SET was done as a superuser or not. The plperl regression tests contain an example where this is useful.
* Use callbacks in SlruScanDirectory for the actual actionAlvaro Herrera2011-10-04
| | | | | | | | | | | | Previously, the code assumed that the only possible action to take was to delete files behind a certain cutoff point. The async notify code was already a crock: it used a different "pagePrecedes" function for truncation than for regular operation. By allowing it to pass a callback to SlruScanDirectory it can do cleanly exactly what it needs to do. The clog.c code also had its own use for SlruScanDirectory, which is made a bit simpler with this.
* Remove the custom_variable_classes parameter.Tom Lane2011-10-04
| | | | | | | | | | | | | | | | | This variable provides only marginal error-prevention capability (since it can only check the prefix of a qualified GUC name), and the consensus is that that isn't worth the amount of hassle that maintaining the setting creates for DBAs. So, let's just remove it. With this commit, the system will silently accept a value for any qualified GUC name at all, whether it has anything to do with any known extension or not. (Unqualified names still have to match known built-in settings, though; and you will get a WARNING at extension load time if there's an unrecognized setting with that extension's prefix.) There's still some discussion ongoing about whether to tighten that up and if so how; but if we do come up with a solution, it's not likely to look anything like custom_variable_classes.
* ProcedureCreate neglected to record dependencies on default expressions.Tom Lane2011-10-03
| | | | | | | Thus, an object referenced in a default expression could be dropped while the function remained present. This was unaccountably missed in the original patch to add default parameters for functions. Reported by Pavel Stehule.
* Restructure error handling in reading of postgresql.conf.Tom Lane2011-10-02
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch has two distinct purposes: to report multiple problems in postgresql.conf rather than always bailing out after the first one, and to change the policy for whether changes are applied when there are unrelated errors in postgresql.conf. Formerly the policy was to apply no changes if any errors could be detected, but that had a significant consistency problem, because in some cases specific values might be seen as valid by some processes but invalid by others. This meant that the latter processes would fail to adopt changes in other parameters even though the former processes had done so. The new policy is that during SIGHUP, the file is rejected as a whole if there are any errors in the "name = value" syntax, or if any lines attempt to set nonexistent built-in parameters, or if any lines attempt to set custom parameters whose prefix is not listed in (the new value of) custom_variable_classes. These tests should always give the same results in all processes, and provide what seems a reasonably robust defense against loading values from badly corrupted config files. If these tests pass, all processes will apply all settings that they individually see as good, ignoring (but logging) any they don't. In addition, the postmaster does not abandon reading a configuration file after the first syntax error, but continues to read the file and report syntax errors (up to a maximum of 100 syntax errors per file). The postmaster will still refuse to start up if the configuration file contains any errors at startup time, but these changes allow multiple errors to be detected and reported before quitting. Alexey Klyukin, reviewed by Andy Colson and av (Alexander ?) with some additional hacking by Tom Lane
generated by cgit v1.2.3 (git 2.25.1) at 2025-08-05 00:11:49 +0000