aboutsummaryrefslogtreecommitdiff
path: root/src/backend
Commit message (Collapse)AuthorAge
* Avoid pre-determining index names during CREATE TABLE LIKE parsing.Tom Lane2012-07-16
| | | | | | | | | | | | | | | | | | | | | | | Formerly, when trying to copy both indexes and comments, CREATE TABLE LIKE had to pre-assign names to indexes that had comments, because it made up an explicit CommentStmt command to apply the comment and so it had to know the name for the index. This creates bad interactions with other indexes, as shown in bug #6734 from Daniele Varrazzo: the preassignment logic couldn't take any other indexes into account so it could choose a conflicting name. To fix, add a field to IndexStmt that allows it to carry a comment to be assigned to the new index. (This isn't a user-exposed feature of CREATE INDEX, only an internal option.) Now we don't need preassignment of index names in any situation. I also took the opportunity to refactor DefineIndex to accept the IndexStmt as such, rather than passing all its fields individually in a mile-long parameter list. Back-patch to 9.2, but no further, because it seems too dangerous to change IndexStmt or DefineIndex's API in released branches. The bug exists back to 9.0 where CREATE TABLE LIKE grew the ability to copy comments, but given the lack of prior complaints we'll just let it go unfixed before 9.2.
* Prevent corner-case core dump in rfree().Tom Lane2012-07-15
| | | | | | | | | | | | | rfree() failed to cope with the case that pg_regcomp() had initialized the regex_t struct but then failed to allocate any memory for re->re_guts (ie, the first malloc call in pg_regcomp() failed). It would try to touch the guts struct anyway, and thus dump core. This is a sufficiently narrow corner case that it's not surprising it's never been seen in the field; but still a bug is a bug, so patch all active branches. Noted while investigating whether we need to call pg_regfree after a failure return from pg_regcomp. Other than this bug, it turns out we don't, so adjust comments appropriately.
* Fix walsender processes to establish a SIGALRM handler.Tom Lane2012-07-12
| | | | | | | | | | | | | | | | | | | | | Walsenders must have working SIGALRM handling during InitPostgres, but they set the handler to SIG_IGN so that nothing would happen if a timeout was reached. This could result in two failure modes: * If a walsender participated in a deadlock during its authentication transaction, and was the last to wait in the deadly embrace, the deadlock would not get cleared automatically. This would require somebody to be trying to take out AccessExclusiveLock on multiple system catalogs, so it's not very probable. * If a client failed to respond to a walsender's authentication challenge, the intended disconnect after AuthenticationTimeout wouldn't happen, and the walsender would wait indefinitely for the client. For the moment, fix in back branches only, since this is fixed in a different way in the timeout-infrastructure patch that's awaiting application to HEAD. If we choose not to apply that, then we'll need to do this in HEAD as well.
* Back-patch fix for extraction of fixed prefixes from regular expressions.Tom Lane2012-07-10
| | | | | | Back-patch of commits 628cbb50ba80c83917b07a7609ddec12cda172d0 and c6aae3042be5249e672b731ebeb21875b5343010. This has been broken since 7.3, so back-patch to all supported branches.
* Back-patch addition of pg_wchar-to-multibyte conversion functionality.Tom Lane2012-07-10
| | | | | | | | | Back-patch of commits 72dd6291f216440f6bb61a8733729a37c7e3b2d2, f6a05fd973a102f7e66c491d3f854864b8d24844, and 60e9c224a197aa37abb1aa3aefa3aad42da61f7f. This is needed to support fixing the regex prefix extraction bug in back branches.
* Refactor pattern_fixed_prefix() to avoid dealing in incomplete patterns.Tom Lane2012-07-09
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously, pattern_fixed_prefix() was defined to return whatever fixed prefix it could extract from the pattern, plus the "rest" of the pattern. That definition was sensible for LIKE patterns, but not so much for regexes, where reconstituting a valid pattern minus the prefix could be quite tricky (certainly the existing code wasn't doing that correctly). Since the only thing that callers ever did with the "rest" of the pattern was to pass it to like_selectivity() or regex_selectivity(), let's cut out the middle-man and just have pattern_fixed_prefix's subroutines do this directly. Then pattern_fixed_prefix can return a simple selectivity number, and the question of how to cope with partial patterns is removed from its API specification. While at it, adjust the API spec so that callers who don't actually care about the pattern's selectivity (which is a lot of them) can pass NULL for the selectivity pointer to skip doing the work of computing a selectivity estimate. This patch is only an API refactoring that doesn't actually change any processing, other than allowing a little bit of useless work to be skipped. However, it's necessary infrastructure for my upcoming fix to regex prefix extraction, because after that change there won't be any simple way to identify the "rest" of the regex, not even to the low level of fidelity needed by regex_selectivity. We can cope with that if regex_fixed_prefix and regex_selectivity communicate directly, but not if we have to work within the old API. Hence, back-patch to all active branches.
* Fix planner to pass correct collation to operator selectivity estimators.Tom Lane2012-07-08
| | | | | | | | | | | | | | | | | | | | | | | | | We can do this without creating an API break for estimation functions by passing the collation using the existing fmgr functionality for passing an input collation as a hidden parameter. The need for this was foreseen at the outset, but we didn't get around to making it happen in 9.1 because of the decision to sort all pg_statistic histograms according to the database's default collation. That meant that selectivity estimators generally need to use the default collation too, even if they're estimating for an operator that will do something different. The reason it's suddenly become more interesting is that regexp interpretation also uses a collation (for its LC_TYPE not LC_COLLATE property), and we no longer want to use the wrong collation when examining regexps during planning. It's not that the selectivity estimate is likely to change much from this; rather that we are thinking of caching compiled regexps during planner estimation, and we won't get the intended benefit if we cache them with a different collation than the executor will use. Back-patch to 9.1, both because the regexp change is likely to get back-patched and because we might as well get this right in all collation-supporting branches, in case any third-party code wants to rely on getting the collation. The patch turns out to be minuscule now that I've done it ...
* Run updated copyright.pl on HEAD and 9.2 trees, updating the psqlBruce Momjian2012-07-06
| | | | | | \copyright output to 2012. Backpatch to 9.2.
* Run newly-configured perltidy script on Perl files.Bruce Momjian2012-07-04
| | | | Run on HEAD and 9.2.
* Always treat a standby returning an an invalid flush location as asyncMagnus Hagander2012-07-04
| | | | | | | | This ensures that a standby such as pg_receivexlog will not be selected as sync standby - which would cause the master to block waiting for a location that could never happen. Fujii Masao
* Forgot an #include in the previous patch :-(Alvaro Herrera2012-07-03
|
* Have REASSIGN OWNED work on extensions, tooAlvaro Herrera2012-07-03
| | | | | | | | | | | | | | | | | Per bug #6593, REASSIGN OWNED fails when the affected role has created an extension. Even though the user related to the extension is not nominally the owner, its OID appears on pg_shdepend and thus causes problems when the user is to be dropped. This commit adds code to change the "ownership" of the extension itself, not of the contained objects. This is fine because it's currently only called from REASSIGN OWNED, which would also modify the ownership of the contained objects. However, this is not sufficient for a working ALTER OWNER implementation extension. Back-patch to 9.1, where extensions were introduced. Bug #6593 reported by Emiliano Leporati.
* Assorted message style improvementsPeter Eisentraut2012-07-02
|
* Add missing space in event_source GUC description.Peter Eisentraut2012-07-02
| | | | | | This has apparently been wrong since event_source was added. Alexander Lakhin
* Fix to_date's handling of year 519.Tom Lane2012-07-02
| | | | | | | | A thinko in commit 029dfdf1157b6d837a7b7211cd35b00c6bcd767c caused the year 519 to be handled differently from either adjacent year, which was not the intention AFAICS. Report and diagnosis by Marc Cousin. In passing, remove redundant re-tests of year value.
* Fix race condition in enum value comparisons.Tom Lane2012-07-01
| | | | | | | | | | | | | | | | | | | | | | | | When (re) loading the typcache comparison cache for an enum type's values, use an up-to-date MVCC snapshot, not the transaction's existing snapshot. This avoids problems if we encounter an enum OID that was created since our transaction started. Per report from Andres Freund and diagnosis by Robert Haas. To ensure this is safe even if enum comparison manages to get invoked before we've set a transaction snapshot, tweak GetLatestSnapshot to redirect to GetTransactionSnapshot instead of throwing error when FirstSnapshotSet is false. The existing uses of GetLatestSnapshot (in ri_triggers.c) don't care since they couldn't be invoked except in a transaction that's already done some work --- but it seems just conceivable that this might not be true of enums, especially if we ever choose to use enums in system catalogs. Note that the comparable coding in enum_endpoint and enum_range_internal remains GetTransactionSnapshot; this is perhaps debatable, but if we changed it those functions would have to be marked volatile, which doesn't seem attractive. Back-patch to 9.1 where ALTER TYPE ADD VALUE was added.
* Remove inappropriate semicolons after function definitions.Tom Lane2012-06-30
| | | | | Solaris Studio warns about this, and some compilers might think it's an outright syntax error.
* Prevent CREATE TABLE LIKE/INHERITS from (mis) copying whole-row Vars.Tom Lane2012-06-30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | If a CHECK constraint or index definition contained a whole-row Var (that is, "table.*"), an attempt to copy that definition via CREATE TABLE LIKE or table inheritance produced incorrect results: the copied Var still claimed to have the rowtype of the source table, rather than the created table. For the LIKE case, it seems reasonable to just throw error for this situation, since the point of LIKE is that the new table is not permanently coupled to the old, so there's no reason to assume its rowtype will stay compatible. In the inheritance case, we should ideally allow such constraints, but doing so will require nontrivial refactoring of CREATE TABLE processing (because we'd need to know the OID of the new table's rowtype before we adjust inherited CHECK constraints). In view of the lack of previous complaints, that doesn't seem worth the risk in a back-patched bug fix, so just make it throw error for the inheritance case as well. Along the way, replace change_varattnos_of_a_node() with a more robust function map_variable_attnos(), which is capable of being extended to handle insertion of ConvertRowtypeExpr whenever we get around to fixing the inheritance case nicely, and in the meantime it returns a failure indication to the caller so that a helpful message with some context can be thrown. Also, this code will do the right thing with subselects (if we ever allow them in CHECK or indexes), and it range-checks varattnos before using them to index into the map array. Per report from Sergey Konoplev. Back-patch to all supported branches.
* Initialize shared memory copy of ckptXidEpoch correctly when not in recovery.Heikki Linnakangas2012-06-29
| | | | | | | This bug was introduced by commit 20d98ab6e4110087d1816cd105a40fcc8ce0a307, so backpatch this to 9.0-9.2 like that one. This fixes bug #6710, reported by Tarvi Pillessaar
* Fix NOTIFY to cope with I/O problems, such as out-of-disk-space.Tom Lane2012-06-29
| | | | | | | | | | | | | The LISTEN/NOTIFY subsystem got confused if SimpleLruZeroPage failed, which would typically happen as a result of a write() failure while attempting to dump a dirty pg_notify page out of memory. Subsequently, all attempts to send more NOTIFY messages would fail with messages like "Could not read from file "pg_notify/nnnn" at offset nnnnn: Success". Only restarting the server would clear this condition. Per reports from Kevin Grittner and Christoph Berg. Back-patch to 9.0, where the problem was introduced during the LISTEN/NOTIFY rewrite.
* Make UtilityContainsQuery recurse until it finds a non-utility Query.Tom Lane2012-06-27
| | | | | | | | | | | | | | | | | | The callers of UtilityContainsQuery want it to return a non-utility Query if it returns anything at all. However, since we made CREATE TABLE AS/SELECT INTO into a utility command instead of a variant of SELECT, a command like "EXPLAIN SELECT INTO" results in two nested utility statements. So what we need UtilityContainsQuery to do is drill down to the bottom non-utility Query. I had thought of this possibility in setrefs.c, and fixed it there by looping around the UtilityContainsQuery call; but overlooked that the call sites in plancache.c have a similar issue. In those cases it's notationally inconvenient to provide an external loop, so let's redefine UtilityContainsQuery as recursing down to a non-utility Query instead. Noted by Rushabh Lathia. This is a somewhat cleaned-up version of his proposed patch.
* Allow pg_terminate_backend() to be used on backends with matching role.Robert Haas2012-06-27
| | | | | | | | A similar change was made previously for pg_cancel_backend, so now it all matches again. Dan Farina, reviewed by Fujii Masao, Noah Misch, and Jeff Davis, with slight kibitzing on the doc changes by me.
* Cope with smaller-than-normal BLCKSZ setting in SPGiST indexes on text.Tom Lane2012-06-26
| | | | | | | | | | | | The original coding failed miserably for BLCKSZ of 4K or less, as reported by Josh Kupershmidt. With the present design for text indexes, a given inner tuple could have up to 256 labels (requiring either 3K or 4K bytes depending on MAXALIGN), which means that we can't positively guarantee no failures for smaller blocksizes. But we can at least make it behave sanely so long as there are few enough labels to fit on a page. Considering that btree is also more prone to "index tuple too large" failures when BLCKSZ is small, it's not clear that we should expend more work than this on this case.
* Fix memory leak in ARRAY(SELECT ...) subqueries.Tom Lane2012-06-21
| | | | | | | | | | | Repeated execution of an uncorrelated ARRAY_SUBLINK sub-select (which I think can only happen if the sub-select is embedded in a larger, correlated subquery) would leak memory for the duration of the query, due to not reclaiming the array generated in the previous execution. Per bug #6698 from Armando Miraglia. Diagnosis and fix idea by Heikki, patch itself by me. This has been like this all along, so back-patch to all supported versions.
* Make documentation of --help and --version options more consistentPeter Eisentraut2012-06-18
| | | | | | Before, some places didn't document the short options (-? and -V), some documented both, some documented nothing, and they were listed in various orders. Now this is hopefully more consistent and complete.
* Improve reporting of permission errors for array typesPeter Eisentraut2012-06-15
| | | | | | | | | | | | | Because permissions are assigned to element types, not array types, complaining about permission denied on an array type would be misleading to users. So adjust the reporting to refer to the element type instead. In order not to duplicate the required logic in two dozen places, refactor the permission denied reporting for types a bit. pointed out by Yeb Havinga during the review of the type privilege feature
* Add more message pluralizationPeter Eisentraut2012-06-15
| | | | | Even though we can't do much about the case with multiple plurals in one sentence, we can fix the other cases.
* Revisit error message details for JSON input parsing.Tom Lane2012-06-13
| | | | | | | | | Instead of identifying error locations only by line number (which could be entirely unhelpful with long input lines), provide a fragment of the input text too, placing this info in a new CONTEXT entry. Make the error detail messages conform more closely to style guidelines, fix failure to expose some of them for translation, ensure compiler can check formats against supplied parameters.
* Revert "Reduce checkpoints and WAL traffic on low activity database server"Tom Lane2012-06-13
| | | | | | | | | | | | | This reverts commit 18fb9d8d21a28caddb72c7ffbdd7b96d52ff9724. Per discussion, it does not seem like a good idea to allow committed changes to go un-checkpointed indefinitely, as could happen in a low-traffic server; that makes us entirely reliant on the WAL stream with no redundancy that might aid data recovery in case of disk failure. This re-introduces the original problem of hot-standby setups generating a small continuing stream of WAL traffic even when idle, but there are other ways to address that without compromising crash recovery, so we'll revisit that issue in a future release cycle.
* Deprecate use of GLOBAL and LOCAL in temp table creation.Tom Lane2012-06-13
| | | | | | | | | | | | | Aside from adjusting the documentation to say that these are deprecated, we now report a warning (not an error) for use of GLOBAL, since it seems fairly likely that we might change that to request SQL-spec-compliant temp table behavior in the foreseeable future. Although our handling of LOCAL is equally nonstandard, there is no evident interest in ever implementing SQL modules, and furthermore some other products interpret LOCAL as behaving the same way we do. So no expectation of change and no warning for LOCAL; but it still seems a good idea to deprecate writing it. Noah Misch
* Support Linux's oom_score_adj API as well as the older oom_adj API.Tom Lane2012-06-13
| | | | | | | | | The simplest way to handle this is just to copy-and-paste the relevant code block in fork_process.c, so that's what I did. (It's possible that something more complicated would be useful to packagers who want to work with either the old or the new API; but at this point the number of such people is rapidly approaching zero, so let's just get the minimal thing done.) Update relevant documentation as well.
* Improve documentation of postgres -C optionPeter Eisentraut2012-06-13
| | | | | | Clarify help (s/return/print/), and explain that this option is for use by other programs, not for user-facing use (it does not print units).
* Minor code review for json.c.Tom Lane2012-06-12
| | | | | Improve commenting, conform to project style for use of ++ etc. No functional changes.
* Mark JSON error detail messages for translation.Robert Haas2012-06-12
| | | | Per gripe from Tom Lane.
* Prevent non-streaming replication connections from being selected sync slaveMagnus Hagander2012-06-11
| | | | | | | | | | | | This prevents a pg_basebackup backup session that just does a base backup (no xlog involved at all) from becoming the synchronous slave and thus blocking all access while it runs. Also fixes the problem when a higher priority slave shows up it would become the sync standby before it has reached the STREAMING state, by making sure we can only switch to a walsender that's actually STREAMING. Fujii Masao
* Run pgindent on 9.2 source tree in preparation for first 9.3Bruce Momjian2012-06-10
| | | | commit-fest.
* Revert error message on GLOBAL/LOCAL pending further discussionSimon Riggs2012-06-10
|
* Add ERROR msg for GLOBAL/LOCAL TEMP is not yet implementedSimon Riggs2012-06-09
|
* Fix bug in early startup of Hot Standby with subtransactions.Simon Riggs2012-06-08
| | | | | | | | | | When HS startup is deferred because of overflowed subtransactions, ensure that we re-initialize KnownAssignedXids for when both existing and incoming snapshots have non-zero qualifying xids. Fixes bug #6661 reported by Valentine Gogichashvili. Analysis and fix by Andres Freund
* Scan the buffer pool just once, not once per fork, during relation drop.Tom Lane2012-06-07
| | | | | | | | This provides a speedup of about 4X when NBuffers is large enough. There is also a useful reduction in sinval traffic, since we only do CacheInvalidateSmgr() once not once per fork. Simon Riggs, reviewed and somewhat revised by Tom Lane
* Do unlocked prechecks in bufmgr.c loops that scan the whole buffer pool.Tom Lane2012-06-07
| | | | | | | | | | | | | | | | | | | | DropRelFileNodeBuffers, DropDatabaseBuffers, FlushRelationBuffers, and FlushDatabaseBuffers have to scan the whole shared_buffers pool because we have no index structure that would find the target buffers any more efficiently than that. This gets expensive with large NBuffers. We can shave some cycles from these loops by prechecking to see if the current buffer is interesting before we acquire the buffer header lock. Ordinarily such a test would be unsafe, but in these cases it should be safe because we are already assuming that the caller holds a lock that prevents any new target pages from being loaded into the buffer pool concurrently. Therefore, no buffer tag should be changing to a value of interest, only away from a value of interest. So a false negative match is impossible, while a false positive is safe because we'll recheck after acquiring the buffer lock. Initial testing says that this speeds these loops by a factor of 2X to 3X on common Intel hardware. Patch for DropRelFileNodeBuffers by Jeff Janes (based on an idea of Heikki's); extended to the remaining sequential scans by Tom Lane
* Wake WALSender to reduce data loss at failover for async commit.Simon Riggs2012-06-07
| | | | | | | | | WALSender now woken up after each background flush by WALwriter, avoiding multi-second replication delay for an all-async commit workload. Replication delay reduced from 7s with default settings to 200ms and often much less, allowing significantly reduced data loss at failover. Andres Freund and Simon Riggs
* Fix more crash-safe visibility map bugs, and improve comments.Robert Haas2012-06-07
| | | | | | | | | | | | | | | | | | | | | | | | | In lazy_scan_heap, we could issue bogus warnings about incorrect information in the visibility map, because we checked the visibility map bit before locking the heap page, creating a race condition. Fix by rechecking the visibility map bit before we complain. Rejigger some related logic so that we rely on the possibly-outdated all_visible_according_to_vm value as little as possible. In heap_multi_insert, it's not safe to clear the visibility map bit before beginning the critical section. The visibility map is not crash-safe unless we treat clearing the bit as a critical operation. Specifically, if the transaction were to error out after we set the bit and before entering the critical section, we could end up writing the heap page to disk (with the bit cleared) and crashing before the visibility map page made it to disk. That would be bad. heap_insert has this correct, but somehow the order of operations got rearranged when heap_multi_insert was added. Also, add some more comments to visibilitymap_test, lazy_scan_heap, and IndexOnlyNext, expounding on concurrency issues. Per extensive code review by Andres Freund, and further review by Tom Lane, who also made the original report about the bogus warnings.
* Fix bogus handling of control characters in json_lex_string().Tom Lane2012-06-04
| | | | | | | | | The original coding misbehaved if "char" is signed, and also made the extremely poor decision to print control characters literally when trying to complain about them. Report and patch by Shigeru Hanada. In passing, also fix core dump risk in report_parse_error() should the parse state be something other than what it expects.
* Avoid early reuse of btree pages, causing incorrect query results.Simon Riggs2012-06-01
| | | | | | | | | | | | | When we allowed read-only transactions to skip assigning XIDs we introduced the possibility that a fully deleted btree page could be reused. This broke the index link sequence which could then lead to indexscans silently returning fewer rows than would have been correct. The actual incidence of silent errors from this is thought to be very low because of the exact workload required and locking pre-conditions. Fix is to remove pages only if index page opaque->btpo.xact precedes RecentGlobalXmin. Noah Misch, reviewed by Simon Riggs
* After any checkpoint, close all smgr files handles in bgwriterSimon Riggs2012-06-01
|
* Checkpointer starts before bgwriter to avoid missing fsync requests.Simon Riggs2012-06-01
| | | | Noted while testing Hot Standby startup.
* Provide interim statistics while in mid-checkpoint.Simon Riggs2012-06-01
| | | | | | | Re-implements similar functionality in 9.1 and previously which was removed during split of checkpointer and bgwriter. Requested/spotted by Magnus Hagander
* Improve comment for GetStableLatestTransactionId().Tom Lane2012-05-31
|
* Only throw recovery conflicts when InHotStandby. Bug fix to recentSimon Riggs2012-05-31
| | | | | | patch to allow Index Only Scans on Hot Standby. Bug report from Jaime Casanova
generated by cgit v1.2.3 (git 2.25.1) at 2025-08-03 17:38:17 +0000