aboutsummaryrefslogtreecommitdiff
path: root/src/backend
Commit message (Collapse)AuthorAge
...
* Improve page split in rtree emulation. Now if splitted result hasTeodor Sigaev2007-09-07
| | | | | | | big misalignement, then it tries to split page basing on distribution of boxe's centers. Per report from Dolafi, Tom <dolafit@janelia.hhmi.org>
* Fix brain fade in DefineIndex(): it was continuing to access the table'sTom Lane2007-08-25
| | | | | | | | | | | | | | | relcache entry after having heap_close'd it. This could lead to misbehavior if a relcache flush wiped out the cache entry meanwhile. In 8.2 there is a very real risk of CREATE INDEX CONCURRENTLY using the wrong relid for locking and waiting purposes. I think the bug is only cosmetic in 8.0 and 8.1, because their transgression is limited to using RelationGetRelationName(rel) in an ereport message immediately after heap_close, and there's no way (except with special debugging options) for a cache flush to occur in that interval. Not quite sure that it's cosmetic in 7.4, but seems best to patch anyway. Found by trying to run the regression tests with CLOBBER_CACHE_ALWAYS enabled. Maybe we should try to do that on a regular basis --- it's awfully slow, but perhaps some fast buildfarm machine could do it once in awhile.
* Fix potential access-off-the-end-of-memory in varbit_out(): it fetched theTom Lane2007-08-21
| | | | | | byte after the last full byte of the bit array, regardless of whether that byte was part of the valid data or not. Found by buildfarm testing. Thanks to Stefan Kaltenbrunner for nailing down the cause.
* Repair problems occurring when multiple RI updates have to be done to the sameTom Lane2007-08-15
| | | | | | | | | row within one query: we were firing check triggers before all the updates were done, leading to bogus failures. Fix by making the triggers queued by an RI update go at the end of the outer query's trigger event list, thereby effectively making the processing "breadth-first". This was indeed how it worked pre-8.0, so the bug does not occur in the 7.x branches. Per report from Pavel Stehule.
* Fix a gradual memory leak in ExecReScanAgg(). Because the aggregationNeil Conway2007-08-08
| | | | | | | | | | | | hash table is allocated in a child context of the agg node's memory context, MemoryContextReset() will reset but *not* delete the child context. Since ExecReScanAgg() proceeds to build a new hash table from scratch (in a new sub-context), this results in leaking the header for the previous memory context. Therefore, use MemoryContextResetAndDeleteChildren() instead. Credit: My colleague Sailesh Krishnamurthy at Truviso for isolating the cause of the leak.
* Suppress time zone name (%Z) when logging timestamps in xlog.c startupTom Lane2007-08-04
| | | | | | | on Windows. This is yet another manifestation of the problem that Windows returns time zone names that may be in a different encoding than we are using. I've put a better solution in HEAD, but the back branches need a simple patch. Per report from Hiroshi Saito.
* Make sure syslogPipe runs in binary mode on Windows to avoid corrupting the ↵Andrew Dunstan2007-08-02
| | | | pipe chunking protocol. Backport to 8.0
* Fix a memory leak in tuplestore_end(). Unlikely to be significant duringNeil Conway2007-08-02
| | | | normal operation, but tuplestore_end() ought to do what it claims to do.
* Fix a bug in the original implementation of redundant-join-clause removal:Tom Lane2007-07-31
| | | | | | clauses in which one side or the other references both sides of the join cannot be removed as redundant, because that expression won't have been constrained below the join. Per report from Sergey Burladyan.
* Fix security definer functions with polymorphic arguments. This case hasTom Lane2007-07-31
| | | | | never worked because fmgr_security_definer() neglected to pass the fn_expr information through. Per report from Viatcheslav Kalinin.
* Fix elog.c to avoid infinite recursion (leading to backend crash) whenTom Lane2007-07-21
| | | | | | | | | | log_min_error_statement is active and there is some problem in logging the current query string; for example, that it's too long to include in the log message without running out of memory. This problem has existed since the log_min_error_statement feature was introduced. No doubt the reason it wasn't detected long ago is that 8.2 is the first release that defaults log_min_error_statement to less than PANIC level. Per report from Bill Moran.
* Fix WAL replay of truncate operations to cope with the possibility that theTom Lane2007-07-20
| | | | | | | | | truncated relation was deleted later in the WAL sequence. Since replay normally auto-creates a relation upon its first reference by a WAL log entry, failure is seen only if the truncate entry happens to be the first reference after the checkpoint we're restarting from; which is a pretty unusual case but of course not impossible. Fix by making truncate entries auto-create like the other ones do. Per report and test case from Dharmendra Goyal.
* Make replace(), split_part(), and string_to_array() behave somewhat sanelyTom Lane2007-07-19
| | | | | | | | | when handed an invalidly-encoded pattern. The previous coding could get into an infinite loop if pg_mb2wchar_with_len() returned a zero-length string after we'd tested for nonempty pattern; which is exactly what it will do if the string consists only of an incomplete multibyte character. This led to either an out-of-memory error or a backend crash depending on platform. Per report from Wiktor Wodecki.
* Only use the pipe chunking protocol if we know the syslogger shouldAndrew Dunstan2007-07-19
| | | | | | | be catching stderr output, and we are not ourselves the syslogger. Otherwise, go directly to stderr. Bug noticed by Tom Lane. Backpatch as far as 8.0.
* Fix an old thinko in SS_make_initplan_from_plan, which is used when optimizingTom Lane2007-07-18
| | | | | | | | a MIN or MAX aggregate call into an indexscan: the initplan is being made at the current query nesting level and so we shouldn't increment query_level. Though usually harmless, this mistake could lead to bogus "plan should not reference subplan's variable" failures on complex queries. Per bug report from David Sanchez i Gregori.
* Fix incorrect optimization of foreign-key checks. When an UPDATE on theTom Lane2007-07-17
| | | | | | | | | | | | | | referencing table does not change the tuple's FK column(s), we don't bother to check the PK table since the constraint was presumably already valid. However, the check is still necessary if the tuple was inserted by our own transaction, since in that case the INSERT trigger will conclude it need not make the check (since its version of the tuple has been deleted). We got this right for simple cases, but not when the insert and update are in different subtransactions of the current top-level transaction; in such cases the FK check would never be made at all. (Hence, problem dates back to 8.0 when subtransactions were added --- it's actually the subtransaction version of a bug fixed in 7.3.5.) Fix, and add regression test cases. Report and fix by Affan Salman.
* Fix outfuncs.c to dump A_Const nodes representing NULLs correctly. This hasTom Lane2007-07-17
| | | | | | been broken since forever, but was not noticed because people seldom look at raw parse trees. AFAIK, no impact on users except that debug_print_parse might fail; but patch it all the way back anyway. Per report from Jeff Ross.
* Remove the pgstat_drop_relation() call from smgr_internal_unlink(), becauseTom Lane2007-07-08
| | | | | | | | | | we don't know at that point which relation OID to tell pgstat to forget. The code was passing the relfilenode, which is incorrect, and could possibly cause some other relation's stats to be zeroed out. While we could try to clean this up, it seems much simpler and more reliable to let the next invocation of pgstat_vacuum_tabstat() fix things; which indeed is how it worked before I introduced the buggy code into 8.1.3 and later :-(. Problem noticed by Itagaki Takahiro, fix is per subsequent discussion.
* Fix failure to restart Postgres when Linux kernel returns EIDRM for shmctl().Tom Lane2007-07-02
| | | | | | | | | | | | | This is a Linux kernel bug that apparently exists in every extant kernel version: sometimes shmctl() will fail with EIDRM when EINVAL is correct. We were assuming that EIDRM indicates a possible conflict with pre-existing backends, and refusing to start the postmaster when this happens. Fortunately, there does not seem to be any case where Linux can legitimately return EIDRM (it doesn't track shmem segments in a way that would allow that), so we can get away with just assuming that EIDRM means EINVAL on this platform. Per reports from Michael Fuhr and Jon Lapham --- it's a bit surprising we have not seen more reports, actually.
* Fix a passel of ancient bugs in to_char(), including two distinct bufferTom Lane2007-06-29
| | | | | | | | | | | overruns (neither of which seem likely to be exploitable as security holes, fortunately, since the provoker can't control the data written). One of these is due to choosing to stomp on the output of a called function, which is bad news in any case; make it treat the called functions' results as read-only. Avoid some unnecessary palloc/pfree traffic too; it's not really helpful to free small temporary objects, and again this is presuming more than it ought to about the nature of the results of called functions. Per report from Patrick Welche and additional code-reading by Imad.
* transformColumnDefinition failed to complain aboutTom Lane2007-06-20
| | | | | | create table foo (bar int default null default 3); due to not thinking about the special-case handling of DEFAULT NULL. Problem noticed while investigating bug #3396.
* CREATE DOMAIN ... DEFAULT NULL failed because gram.y special-cases DEFAULTTom Lane2007-06-20
| | | | | NULL and DefineDomain didn't. Bug goes all the way back to original coding of domains. Per bug #3396 from Sergey Burladyan.
* Back-patch 8.2 fix that complains if trying to extend a relation encountersTom Lane2007-06-18
| | | | | | | | | a buffer containing a non-zeroed page. This seems appropriate now that the 8.2 fix has been seen to save at least one user from data loss due to a buggy kernel (per report from Jaime Silvela 7-May-07). I'd go further back than 8.1, except that the 8.0-to-8.1 bufmgr changes are large enough that the patch doesn't work immediately; I'm hesitant to make a change without more extensive analysis than I have time for now.
* Avoid having autovacuum run multiple ANALYZE commands in a single transaction,Alvaro Herrera2007-06-14
| | | | to prevent possible deadlock problems. Per request from Tom Lane.
* Implement a chunking protocol for writes to the syslogger pipe, with messagesAndrew Dunstan2007-06-14
| | | | | | | | | reassembled in the syslogger before writing to the log file. This prevents partial messages from being written, which mucks up log rotation, and messages from different backends being interleaved, which causes garbled logs. Backport as far as 8.0, where the syslogger was introduced. Tom Lane and Andrew Dunstan
* Allow numeric_fac() to be interrupted, since it can take quite a while forTom Lane2007-06-09
| | | | | | large inputs. Also cause it to error out immediately if the result will overflow, instead of grinding through a lot of calculation first. Per gripe from Jim Nasby.
* Avoid losing track of data for shared tables in pgstats. Report by MichaelAlvaro Herrera2007-06-07
| | | | Fuhr, patch from Tom Lane after a messier suggestion by me.
* Oops. Patch didn't work properly for 8.1, so don't backpatch a then-unusedMagnus Hagander2007-06-04
| | | | variable either.
* On win32, retry reading when WSARecv returns WSAEWOULDBLOCK. There seemMagnus Hagander2007-06-04
| | | | | | | to be cases when at least Windows 2000 can do this even though select just indicated that the socket is readable. Per report and analysis from Cyril VELTER.
* On win32, don't use SO_REUSEADDR for TCP sockets.Magnus Hagander2007-06-04
| | | | Per failure on buildfarm member baiji and subsequent discussion.
* Fix erroneous error reporting for overlength input in text_date(),Tom Lane2007-06-02
| | | | text_time(), and text_timetz(). 7.4-vintage bug found by Greg Stark.
* Fix aboriginal bug in BufFileDumpBuffer that would cause it to write theTom Lane2007-06-01
| | | | | | | | wrong data when dumping a bufferload that crosses a component-file boundary. This probably has not been seen in the wild because (a) component files are normally 1GB apiece and (b) non-block-aligned buffer usage is relatively rare. But it's fairly easy to reproduce a problem if one reduces RELSEG_SIZE in a test build. Kudos to Kurt Harriman for spotting the bug.
* Fix performance problems in multi-batch hash joins by ensuring that we selectTom Lane2007-06-01
| | | | | | | | | | a well-randomized batch number even when given a poorly-randomized hash value. This is a bit inefficient but seems the only practical solution given the constraint that we can't change the hash functions in released branches. Per report from Joseph Shraibman. Applied to 8.1 and 8.2 only --- HEAD is getting a cleaner fix, and 8.0 and before use different coding that seems less vulnerable.
* Fix overly-strict sanity check in BeginInternalSubTransaction that made itTom Lane2007-05-30
| | | | | | fail when used in a deferred trigger. Bug goes back to 8.0; no doubt the reason it hadn't been noticed is that we've been discouraging use of user-defined constraint triggers. Per report from Frank van Vugt.
* Fix a bug in input processing for the "interval" type. Previously,Neil Conway2007-05-29
| | | | | | | | "microsecond" and "millisecond" units were not considered valid input by themselves, which caused inputs like "1 millisecond" to be rejected erroneously. Update the docs, add regression tests, and backport to 8.2 and 8.1
* Fix best_inner_indexscan to return both the cheapest-total-cost andTom Lane2007-05-22
| | | | | | | | | | | | cheapest-startup-cost innerjoin indexscans, and make joinpath.c consider both of these (when different) as the inside of a nestloop join. The original design was based on the assumption that indexscan paths always have negligible startup cost, and so total cost is the only important figure of merit; an assumption that's obviously broken by bitmap indexscans. This oversight could lead to choosing poor plans in cases where fast-start behavior is more important than total cost, such as LIMIT and IN queries. 8.1-vintage brain fade exposed by an example from Chuck D.
* Remove redundant logging of send failures when SSL is in use. While pqcomm.cTom Lane2007-05-18
| | | | | | had been taught not to do that ages ago, the SSL code was helpfully bleating anyway. Resolves some recent reports such as bug #3266; however the underlying cause of the related bug #2829 is still unclear.
* Fix a thinko in my patch of a couple months ago for bug #3116: it did theTom Lane2007-05-01
| | | | | | | | | | wrong thing when inlining polymorphic SQL functions, because it was using the function's declared return type where it should have used the actual result type of the current call. In 8.1 and 8.2 this causes obvious failures even if you don't have assertions turned on; in 8.0 and 7.4 it would only be a problem if the inlined expression were used as an input to a function that did run-time type determination on its inputs. Add a regression test, since this is evidently an under-tested area.
* Fix dynahash.c to suppress hash bucket splits while a hash_seq_search() scanTom Lane2007-04-26
| | | | | | | | | | | | | | | | | | | | | | | is in progress on the same hashtable. This seems the least invasive way to fix the recently-recognized problem that a split could cause the scan to visit entries twice or (with much lower probability) miss them entirely. The only field-reported problem caused by this is the "failed to re-find shared lock object" PANIC in COMMIT PREPARED reported by Michel Dorochevsky, which was caused by multiply visited entries. However, it seems certain that mdsync() is vulnerable to missing required fsync's due to missed entries, and I am fearful that RelationCacheInitializePhase2() might be at risk as well. Because of that and the generalized hazard presented by this bug, back-patch all the supported branches. Along the way, fix pg_prepared_statement() and pg_cursor() to not assume that the hashtables they are examining will stay static between calls. This is risky regardless of the newly noted dynahash problem, because hash_seq_search() has never promised to cope with deletion of table entries other than the just-returned one. There may be no bug here because the only supported way to call these functions is via ExecMakeTableFunctionResult() which will cycle them to completion before doing anything very interesting, but it seems best to get rid of the assumption. This affects 8.2 and HEAD only, since those functions weren't there earlier.
* Support explicit placement of the temporary-table schema within search_path.Tom Lane2007-04-20
| | | | | | | | | | | | | This is needed to allow a security-definer function to set a truly secure value of search_path. Without it, a malicious user can use temporary objects to execute code with the privileges of the security-definer function. Even pushing the temp schema to the back of the search path is not quite good enough, because a function or operator at the back of the path might still capture control from one nearer the front due to having a more exact datatype match. Hence, disable searching the temp schema altogether for functions and operators. Security: CVE-2007-2138
* Repair PANIC condition in hash indexes when a previous index extension attemptTom Lane2007-04-19
| | | | | | | | | | | failed (due to lock conflicts or out-of-space). We might have already extended the index's filesystem EOF before failing, causing the EOF to be beyond what the metapage says is the last used page. Hence the invariant maintained by the code needs to be "EOF is at or beyond last used page", not "EOF is exactly the last used page". Problem was created by my patch of 2006-11-19 that attempted to repair bug #2737. Since that was back-patched to 7.4, this needs to be as well. Per report and test case from Vlastimil Krejcir.
* Translation updatesPeter Eisentraut2007-04-18
|
* Rewrite choose_bitmap_and() to make it more robust in the presence ofTom Lane2007-04-17
| | | | | | | | | | | | | | | | | | competing alternatives for indexes to use in a bitmap scan. The former coding took estimated selectivity as an overriding factor, causing it to sometimes choose indexes that were much slower to scan than ones with a slightly worse selectivity. It was also too narrow-minded about which combinations of indexes to consider ANDing. The rewrite makes it pay more attention to index scan cost than selectivity; this seems sane since it's impossible to have very bad selectivity with low cost, whereas the reverse isn't true. Also, we now consider each index alone, as well as adding each index to an AND-group led by each prior index, for a total of about O(N^2) rather than O(N) combinations considered. This makes the results much less dependent on the exact order in which the indexes are considered. It's still a lot cheaper than an O(2^N) exhaustive search. A prefilter step eliminates all but the cheapest of those indexes using the same set of WHERE conditions, to keep the effective value of N down in scenarios where the DBA has created lots of partially-redundant indexes.
* Rearrange mdsync() looping logic to avoid the problem that a sufficientlyTom Lane2007-04-12
| | | | | | | | | | | fast flow of new fsync requests can prevent mdsync() from ever completing. This was an unforeseen consequence of a patch added in Mar 2006 to prevent the fsync request queue from overflowing. Problem identified by Heikki Linnakangas and independently by ITAGAKI Takahiro; fix based on ideas from Takahiro-san, Heikki, and Tom. Back-patch as far as 8.1 because a previous back-patch introduced the problem into 8.1 ...
* Cancel pending fsync requests during WAL replay of DROP DATABASE, per bugTom Lane2007-04-12
| | | | | report from David Darville. Back-patch as far as 8.1, which may or may not have the problem but it seems a safe change anyway.
* Fix check_sql_fn_retval to allow the case where a SQL function declared toTom Lane2007-04-02
| | | | | | | | return void ends with a SELECT, if that SELECT has a single result that is also of type void. Without this, it's hard to write a void function that calls another void function. Per gripe from Peter. Back-patch as far as 8.0.
* Fix pg_wchar_table's maxmblen field of EUC_CN, EUC_TW, MULE_INTERNALTatsuo Ishii2007-03-26
| | | | and GB18030. patches from ITAGAKI Takahiro.
* SPI_cursor_open failed to enforce that only read-only queries could beTom Lane2007-03-17
| | | | | | | executed in read_only mode. This could lead to various relatively-subtle failures, such as an allegedly stable function returning non-stable results. Bug goes all the way back to the introduction of read-only mode in 8.0. Per report from Gaetano Mendola.
* Fix a longstanding bug in VACUUM FULL's handling of update chains. The codeTom Lane2007-03-14
| | | | | | | | | | | | | | | | | | | | | | | did not expect that a DEAD tuple could follow a RECENTLY_DEAD tuple in an update chain, but because the OldestXmin rule for determining deadness is a simplification of reality, it is possible for this situation to occur (implying that the RECENTLY_DEAD tuple is in fact dead to all observers, but this patch does not attempt to exploit that). The code would follow a chain forward all the way, but then stop before a DEAD tuple when backing up, meaning that not all of the chain got moved. This could lead to copying the chain multiple times (resulting in duplicate copies of the live tuple at its end), or leaving dangling index entries behind (which, aside from generating warnings from later vacuums, creates a risk of wrong query results or bogus duplicate-key errors once the heap slot the index entry points to is repopulated). The fix is to recheck HeapTupleSatisfiesVacuum while following a chain forward, and to stop if a DEAD tuple is reached. Each contiguous group of RECENTLY_DEAD tuples will therefore be copied as a separate chain. The patch also adds a couple of extra sanity checks to verify correct behavior. Per report and test case from Pavan Deolasee.
* Fix a race condition that caused pg_database_size() and pg_tablespace_size()Alvaro Herrera2007-03-11
| | | | | | | | | to fail if an object was removed between calls to ReadDir() and stat(). Per discussion in pgsql-hackers. http://archives.postgresql.org/pgsql-hackers/2007-03/msg00671.php Bug report and patch by Michael Fuhr.