aboutsummaryrefslogtreecommitdiff
path: root/src/backend
Commit message (Collapse)AuthorAge
* Create an ALTER DEFAULT PRIVILEGES command, which allows users to adjustTom Lane2009-10-05
| | | | | | | | | | | the privileges that will be applied to subsequently-created objects. Such adjustments are always per owning role, and can be restricted to objects created in particular schemas too. A notable benefit is that users can override the traditional default privilege settings, eg, the PUBLIC EXECUTE privilege traditionally granted by default for functions. Petr Jelinek
* Fix assorted memory leaks in pg_hba.conf parsing. Over a sufficientlyTom Lane2009-10-03
| | | | | | large number of SIGHUP cycles, these would have run the postmaster out of memory. Noted while testing memory-leak scenario in postgresql.conf configuration-change-printing patch.
* Fix a couple of issues in recent patch to print updates to postgresql.confTom Lane2009-10-03
| | | | | | | | | | | | | settings: avoid calling superuser() in contexts where it's not defined, don't leak the transient copies of GetConfigOption output, and avoid the whole exercise in postmaster child processes. I found that actually no current caller of GetConfigOption has any use for its internal check of GUC_SUPERUSER_ONLY. But rather than just remove that entirely, it seemed better to add a parameter indicating whether to enforce the check. Per report from Simon and subsequent testing.
* Fix an oversight in an 8.3-era patch: pgstat_initstats should allow statsTom Lane2009-10-02
| | | | | | to be collected for sequences. Report and fix by Akira Kurosawa
* Make sure that GIN fast-insert and regular code paths enforce the sameTom Lane2009-10-02
| | | | | | | | | | | tuple size limit. Improve the error message for index-tuple-too-large so that it includes the actual size, the limit, and the index name. Sync with the btree occurrences of the same error. Back-patch to 8.4 because it appears that the out-of-sync problem is occurring in the field. Teodor and Tom
* Fix erroneous handling of shared dependencies (ie dependencies on roles)Tom Lane2009-10-02
| | | | | | | | | | | | | | in CREATE OR REPLACE FUNCTION. The original code would update pg_shdepend as if a new function was being created, even if it wasn't, with two bad consequences: pg_shdepend might record the wrong owner for the function, and any dependencies for roles mentioned in the function's ACL would be lost. The fix is very easy: just don't touch pg_shdepend at all when doing a function replacement. Also update the CREATE FUNCTION reference page, which never explained exactly what changes and doesn't change in a function replacement. In passing, fix the CREATE VIEW reference page similarly; there's no code bug there, but the docs didn't say what happens.
* Ensure that a cursor has an immutable snapshot throughout its lifespan.Alvaro Herrera2009-10-02
| | | | | | | | | The old coding was using a regular snapshot, referenced elsewhere, that was subject to having its command counter updated. Fix by creating a private copy of the snapshot exclusively for the cursor. Backpatch to 8.4, which is when the bug was introduced during the snapshot management rewrite.
* Support "samehost" and "samenet" specifications in pg_hba.conf,Tom Lane2009-10-01
| | | | | | by enumerating the machine's IP interfaces to look for a match. Stef Walter
* Fix equivclass.c's not-quite-right strategy for handling X=X clauses.Tom Lane2009-09-29
| | | | | | | | | | | | | The original coding correctly noted that these aren't just redundancies (they're effectively X IS NOT NULL, assuming = is strict). However, they got treated that way if X happened to be in a single-member EquivalenceClass already, which could happen if there was an ORDER BY X clause, for instance. The simplest and most reliable solution seems to be to not try to process such clauses through the EquivalenceClass machinery; just throw them back for traditional processing. The amount of work that'd be needed to be smarter than that seems out of proportion to the benefit. Per bug #5084 from Bernt Marius Johnsen, and analysis by Andrew Gierth.
* Remove no-longer-needed ExecCountSlots infrastructure.Tom Lane2009-09-27
|
* Replace the array-style TupleTable data structure with a simple List ofTom Lane2009-09-27
| | | | | | | | | | | TupleTableSlot nodes. This eliminates the need to count in advance how many Slots will be needed, which seems more than worth the small increase in the amount of palloc traffic during executor startup. The ExecCountSlots infrastructure is now all dead code, but I'll remove it in a separate commit for clarity. Per a comment from Robert Haas.
* Sync psql's scanner with recent changes in backend scanner's flex rules.Tom Lane2009-09-27
| | | | Marko Kreen, Tom Lane
* Simplify the bootstrap (BKI) code by getting rid of a useless table of allTom Lane2009-09-27
| | | | | | | | | | | | the strings seen during the bootstrap run. There might have been some actual point to doing that, many years ago, but as far as I can see the only value now is to conserve a bit of memory. Even if we cared about wasting a megabyte or so during the initdb run, it'd be far more effective to arrange to release memory at the end of each BKI command, instead of intentionally hanging onto strings that might never be used again. Not maintaining the table probably makes it faster too; but the main point of this patch is to get rid of a couple hundred lines of unnecessary and rather crufty code.
* Hmm, seems a lot of the buildfarm is running versions of awk thatTom Lane2009-09-26
| | | | don't have gensub(). Use sub() instead, tedious though it be.
* Revert my ill-considered change that made formrdesc not insert the correctTom Lane2009-09-26
| | | | | | | | relation rowtype OID into the relcache entries it builds. This ensures that catcache copies of the relation tupdescs will be fully correct. While the deficiency doesn't seem to have any effect in the current sources, we have been bitten by not-quite-right catcache tupdescs before, so it seems like a good idea to maintain the rule that they should be right.
* Extend the BKI infrastructure to allow system catalogs to be givenTom Lane2009-09-26
| | | | | | | | | | | | hand-assigned rowtype OIDs, even when they are not "bootstrapped" catalogs that have handmade type rows in pg_type.h. Give pg_database such an OID. Restore the availability of C macros for the rowtype OIDs of the bootstrapped catalogs. (These macros are now in the individual catalogs' .h files, though, not in pg_type.h.) This commit doesn't do anything especially useful by itself, but it's necessary infrastructure for reverting some ill-considered changes in relcache.c.
* Fix RelationCacheInitializePhase2 (Phase3, in HEAD) to cope with theTom Lane2009-09-26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | possibility of shared-inval messages causing a relcache flush while it tries to fill in missing data in preloaded relcache entries. There are actually two distinct failure modes here: 1. The flush could delete the next-to-be-processed cache entry, causing the subsequent hash_seq_search calls to go off into the weeds. This is the problem reported by Michael Brown, and I believe it also accounts for bug #5074. The simplest fix is to restart the hashtable scan after we've read any new data from the catalogs. It appears that pre-8.4 branches have not suffered from this failure, because by chance there were no other catalogs sharing the same hash chains with the catalogs that RelationCacheInitializePhase2 had work to do for. However that's obviously pretty fragile, and it seems possible that derivative versions with additional system catalogs might be vulnerable, so I'm back-patching this part of the fix anyway. 2. The flush could delete the *current* cache entry, in which case the pointer to the newly-loaded data would end up being stored into an already-deleted Relation struct. As long as it was still deleted, the only consequence would be some leaked space in CacheMemoryContext. But it seems possible that the Relation struct could already have been recycled, in which case this represents a hard-to-reproduce clobber of cached data structures, with unforeseeable consequences. The fix here is to pin the entry while we work on it. In passing, also change RelationCacheInitializePhase2 to Assert that formrdesc() set up the relation's cached TupleDesc (rd_att) with the correct type OID and hasoids values. This is more appropriate than silently updating the values, because the original tupdesc might already have been copied into the catcache. However this part of the patch is not in HEAD because it fails due to some questionable recent changes in formrdesc :-(. That will be cleaned up in a subsequent patch.
* Prevent isolated second surrogate in U& syntaxPeter Eisentraut2009-09-25
|
* Remove backup states from Unicode escapes patchPeter Eisentraut2009-09-25
|
* Unicode escapes in E'...' stringsPeter Eisentraut2009-09-22
| | | | Author: Marko Kreen <markokr@gmail.com>
* Implement the DO statement to support execution of PL code without havingTom Lane2009-09-22
| | | | | | | | | | | | | | to create a function for it. Procedural languages now have an additional entry point, namely a function to execute an inline code block. This seemed a better design than trying to hide the transient-ness of the code from the PL. As of this patch, only plpgsql has an inline handler, but probably people will soon write handlers for the other standard PLs. In passing, remove the long-dead LANCOMPILER option of CREATE LANGUAGE. Petr Jelinek
* Fix crash if a DROP is attempted on an internally-dependent object.Tom Lane2009-09-22
| | | | | Introduced in 8.4 rewrite of dependency.c. Per bug #5072 from Amit Khandekar.
* Surrogate pair support for U& string and identifier syntaxPeter Eisentraut2009-09-21
| | | | | This is mainly to make the functionality consistent with the proposed \u escape syntax.
* Define a new, more extensible syntax for COPY options.Tom Lane2009-09-21
| | | | | | | | | This is intentionally similar to the recently revised syntax for EXPLAIN options, ie, (name value, ...). The old syntax is still supported for backwards compatibility, but we intend that any options added in future will be provided only in the new syntax. Robert Haas, Emmanuel Cecchet
* Rename new subroutine, per discussion with Robert Haas.Tom Lane2009-09-19
|
* Marginal code cleanup in joinpath.c: factor out clause variable-membershipTom Lane2009-09-18
| | | | | tests into a small common subroutine, and eliminate an unnecessary difference in the order in which conditions are tested. Per a comment from Robert Haas.
* Fix incorrect arguments for gist_box_penalty call. The bug could be observedTeodor Sigaev2009-09-18
| | | | | | only for secondary page split (i.e. for non-first columns of index) Patch by Paul Ramsey <pramsey@opengeo.org>
* Improve wording of error message when a postgresql.conf setting isPeter Eisentraut2009-09-17
| | | | | ignored because it can only be set at server start. In particular, hiding the main reason in the detail message was suboptimal.
* When reloading postgresql.conf, log what parameters actually changedPeter Eisentraut2009-09-17
|
* Implement "join removal" for cases where the inner side of a left joinTom Lane2009-09-17
| | | | | | | | | | | | | | is unique and is not referenced above the join. In this case the inner side doesn't affect the query result and can be thrown away entirely. Although perhaps nobody would ever write such a thing by hand, it's a reasonably common case in machine-generated SQL. The current implementation only recognizes the case where the inner side is a simple relation with a unique index matching the query conditions. This is enough for the use-cases that have been shown so far, but we might want to try to handle other cases later. Robert Haas, somewhat rewritten by Tom
* Fix two distinct errors in creation of GIN_INSERT_LISTPAGE xlog records.Tom Lane2009-09-15
| | | | | | | | | | | | | | | | | In practice these mistakes were always masked when full_page_writes was on, because XLogInsert would always choose to log the full page, and then ginRedoInsertListPage wouldn't try to do anything. But with full_page_writes off a WAL replay failure was certain. The GIN_INSERT_LISTPAGE record type could probably be eliminated entirely in favor of using XLOG_HEAP_NEWPAGE, but I refrained from doing that now since it would have required a significantly more invasive patch. In passing do a little bit of code cleanup, including making the accounting for free space on GIN list pages more precise. (This wasn't a bug as the errors were always in the conservative direction.) Per report from Simon. Back-patch to 8.4 which contains the identical code.
* Fix possible buffer overrun and/or unportable behavior in pg_md5_encrypt()Tom Lane2009-09-15
| | | | | | | if salt_len == 0. This seems to be mostly academic, since nearly all calling code paths guarantee nonempty salt; the only case that doesn't is PQencryptPassword where the caller could mistakenly pass an empty username. So, fix it but don't bother backpatching. Per ljb.
* Don't error out if recycling or removing an old WAL segment fails at the endHeikki Linnakangas2009-09-13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | of checkpoint. Although the checkpoint has been written to WAL at that point already, so that all data is safe, and we'll retry removing the WAL segment at the next checkpoint, if such a failure persists we won't be able to remove any other old WAL segments either and will eventually run out of disk space. It's better to treat the failure as non-fatal, and move on to clean any other WAL segment and continue with any other end-of-checkpoint cleanup. We don't normally expect any such failures, but on Windows it can happen with some anti-virus or backup software that lock files without FILE_SHARE_DELETE flag. Also, the loop in pgrename() to retry when the file is locked was broken. If a file is locked on Windows, you get ERROR_SHARE_VIOLATION, not ERROR_ACCESS_DENIED, at least on modern versions. Fix that, although I left the check for ERROR_ACCESS_DENIED in there as well (presumably it was correct in some environment), and added ERROR_LOCK_VIOLATION to be consistent with similar checks in pgwin32_open(). Reduce the timeout on the loop from 30s to 10s, on the grounds that since it's been broken, we've effectively had a timeout of 0s and no-one has complained, so a smaller timeout is actually closer to the old behavior. A longer timeout would mean that if recycling a WAL file fails because it's locked for some reason, InstallXLogFileSegment() will hold ControlFileLock for longer, potentially blocking other backends, so a long timeout isn't totally harmless. While we're at it, set errno correctly in pgrename(). Backpatch to 8.2, which is the oldest version supported on Windows. The xlog.c changes would make sense on other platforms and thus on older versions as well, but since there's no such locking issues on other platforms, it's not worth it.
* Rewrite the planner's handling of materialized plan types so that there isTom Lane2009-09-12
| | | | | | | | | | | | | | | | an explicit model of rescan costs being different from first-time costs. The costing of Material nodes in particular now has some visible relationship to the actual runtime behavior, where before it was essentially fantasy. This also fixes up a couple of places where different materialized plan types were treated differently for no very good reason (probably just oversights). A couple of the regression tests are affected, because the planner now chooses to put the other relation on the inside of a nestloop-with-materialize. So far as I can see both changes are sane, and the planner is now more consistently following the expectation that it should prefer to materialize the smaller of two relations. Per a recent discussion with Robert Haas.
* Install a hopefully-temporary workaround for Snow Leopard readdir() bug.Tom Lane2009-09-12
| | | | | | | If Apple doesn't fix that reasonably soon, we'll have to consider back-patching a workaround; but for now, just hack it in HEAD so that we can get buildfarm reports on HEAD from OS X machines. Per Jan Otto.
* Fix assertion failure when a SELECT DISTINCT ON expression is volatile.Tom Lane2009-09-12
| | | | | | | | | | | | | | In this case we generate two PathKey references to the expression (one for DISTINCT and one for ORDER BY) and they really need to refer to the same EquivalenceClass. However get_eclass_for_sort_expr was being overly paranoid and creating two different EC's. Correct behavior is to use the SortGroupRef index to decide whether two references to volatile expressions that are equal() (ie textually equivalent) should be considered the same. Backpatch to 8.4. Possibly this should be changed in 8.3 as well, but I'll refrain in the absence of evidence of a visible failure in that branch. Per bug #5049.
* Increase the maximum value of extra_float_digits to 3, and have pg_dumpTom Lane2009-09-11
| | | | | | | use that value when the backend is new enough to allow it. This responds to bug report from Keh-Cheng Chu pointing out that although 2 extra digits should be sufficient to dump and restore float8 exactly, it is possible to need 3 extra digits for float4 values.
* On Windows, when a file is deleted and another process still has an openHeikki Linnakangas2009-09-10
| | | | | | | | | | | | | | | file handle on it, the file goes into "pending deletion" state where it still shows up in directory listing, but isn't accessible otherwise. That confuses RemoveOldXLogFiles(), making it think that the file hasn't been archived yet, while it actually was, and it was deleted along with the .done file. Fix that by renaming the file with ".deleted" extension before deleting it. Also check the return value of rename() and unlink(), so that if the removal fails for any reason (e.g another process is holding the file locked), we don't delete the .done file until the WAL file is really gone. Backpatch to 8.2, which is the oldest version supported on Windows.
* Fix/improve bytea and boolean support in PL/PythonPeter Eisentraut2009-09-09
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Before, PL/Python converted data between SQL and Python by going through a C string representation. This broke for bytea in two ways: - On input (function parameters), you would get a Python string that contains bytea's particular external representation with backslashes etc., instead of a sequence of bytes, which is what you would expect in a Python environment. This problem is exacerbated by the new bytea output format. - On output (function return value), null bytes in the Python string would cause truncation before the data gets stored into a bytea datum. This is now fixed by converting directly between the PostgreSQL datum and the Python representation. The required generalized infrastructure also allows for other improvements in passing: - When returning a boolean value, the SQL datum is now true if and only if Python considers the value that was passed out of the PL/Python function to be true. Previously, this determination was left to the boolean data type input function. So, now returning 'foo' results in true, because Python considers it true, rather than false because PostgreSQL considers it false. - On input, we can convert the integer and float types directly to their Python equivalents without having to go through an intermediate string representation. original patch by Caleb Welton, with updates by myself
* Fix bug with WITH RECURSIVE immediately inside WITH RECURSIVE. 99% of theTom Lane2009-09-09
| | | | | | | | | | | code was already okay with this, but the hack that obtained the output column types of a recursive union in advance of doing real parse analysis of the recursive union forgot to handle the case where there was an inner WITH clause available to the non-recursive term. Best fix seems to be to refactor so that we don't need the "throwaway" parse analysis step at all. Instead, teach the transformSetOperationStmt code to set up the CTE's output column information after it's processed the non-recursive term normally. Per report from David Fetter.
* Add a boolean GUC parameter "bonjour" to control whether a Bonjour-enabledTom Lane2009-09-08
| | | | | | | | build actually attempts to advertise itself via Bonjour. Formerly it always did so, which meant that packagers had to decide for their users whether this behavior was wanted or not. The default is "off" to be on the safe side, though this represents a change in the default behavior of a Bonjour-enabled build. Per discussion.
* Replace use of the long-deprecated Bonjour API DNSServiceRegistrationCreateTom Lane2009-09-08
| | | | | | | with the not-so-deprecated DNSServiceRegister. This patch shouldn't change any user-visible behavior, it just gets rid of a deprecation warning in --with-bonjour builds. The new code will fail on OS X releases before 10.3, but it seems unlikely that anyone will want to run Postgres 8.5 on 10.2.
* Put back "ifeq ($(PORTNAME), solaris)", this time with some documentationTom Lane2009-09-05
| | | | of why it's not as broken as it appears on first glance.
* Revert ill-considered restriction of dtrace support to Solaris only.Tom Lane2009-09-04
|
* Remove pgstat's discrimination against MsgVacuum and MsgAnalyze messages.Tom Lane2009-09-04
| | | | | | | | | | | | | | | Formerly, these message types would be discarded unless there was already a stats hash table entry for the target table. However, the intent of saving hash table space for unused tables was subverted by the fact that the physical I/O done by the vacuum or analyze would result in an immediately following tabstat message, which would create the hash table entry anyway. All that we had left was surprising loss of statistical data, as in a recent complaint from Jaime Casanova. It seems unlikely that a real database would have many tables that go totally untouched over the long haul, so the consensus is that this "optimization" serves little purpose anyhow. Remove it, and just create the hash table entry on demand in all cases.
* Tigthen binary receive functions so that they reject values that the textHeikki Linnakangas2009-09-04
| | | | | | | | | input functions don't accept either. While the backend can handle such values fine, they can cause trouble in clients and in pg_dump/restore. This is followup to the original issue on time datatype reported by Andrew McNamara a while ago. Like that one, none of these seem worth back-patching.
* Fix encoding handling in xml binary input function. If the XML header didn'tHeikki Linnakangas2009-09-04
| | | | | | | specify an encoding explicitly, we used to treat it as being in database encoding when we parsed it, but then perform a UTF-8 -> database encoding conversion on it, which was completely bogus. It's now consistently treated as UTF-8.
* Make LOAD of an already-loaded library into a no-op, instead of attemptingTom Lane2009-09-03
| | | | | | | | | | | | | | | | | | | | | | | to unload and re-load the library. The difficulty with unloading a library is that we haven't defined safe protocols for doing so. In particular, there's no safe mechanism for getting out of a "hook" function pointer unless libraries are unloaded in reverse order of loading. And there's no mechanism at all for undefining a custom GUC variable, so GUC would be left with a pointer to an old value that might or might not still be valid, and very possibly wouldn't be in the same place anymore. While the unload and reload behavior had some usefulness in easing development of new loadable libraries, it's of no use whatever to normal users, so just disabling it isn't giving up that much. Someday we might care to expend the effort to develop safe unload protocols; but even if we did, there'd be little certainty that every third-party loadable module was following them, so some security restrictions would still be needed. Back-patch to 8.2; before that, LOAD was superuser-only anyway. Security: unprivileged users could crash backend. CVE not assigned yet
* Disallow RESET ROLE and RESET SESSION AUTHORIZATION inside security-definerTom Lane2009-09-03
| | | | | | | | | | | | | | | | functions. This extends the previous patch that forbade SETting these variables inside security-definer functions. RESET is equally a security hole, since it would allow regaining privileges of the caller; furthermore it can trigger Assert failures and perhaps other internal errors, since the code is not expecting these variables to change in such contexts. The previous patch did not cover this case because assign hooks don't really have enough information, so move the responsibility for preventing this into guc.c. Problem discovered by Heikki Linnakangas. Security: no CVE assigned yet, extends CVE-2007-6600
* Install a workaround for a longstanding gcc bug that allows SIGFPE trapsTom Lane2009-09-03
| | | | | | | | | | | to occur for division by zero, even though the code is carefully avoiding that. All available evidence is that the only functions affected are int24div, int48div, and int28div, so patch just those three functions to include a "return" after the ereport() call. Backpatch to 8.4 so that the fix can be tested in production builds. For older branches our recommendation will continue to be to use -O1 on affected platforms (which are mostly non-mainstream anyway).
generated by cgit v1.2.3 (git 2.25.1) at 2025-08-07 14:16:29 +0000