aboutsummaryrefslogtreecommitdiff
path: root/src/backend
Commit message (Collapse)AuthorAge
* Remove typmod checking from the recent security-related patches. It turnsTom Lane2007-02-06
| | | | | | | | | | | | | out that ExecEvalVar and friends don't necessarily have access to a tuple descriptor with correct typmod: it definitely can contain -1, and possibly might contain other values that are different from the Var's value. Arguably this should be cleaned up someday, but it's not a simple change, and in any case typmod discrepancies don't pose a security hazard. Per reports from numerous people :-( I'm not entirely sure whether the failure can occur in 8.0 --- the simple test cases reported so far don't trigger it there. But back-patch the change all the way anyway.
* Repair failure to check that a table is still compatible with a previouslyTom Lane2007-02-02
| | | | | | | | | | | | | | | | | | | | | | made query plan. Use of ALTER COLUMN TYPE creates a hazard for cached query plans: they could contain Vars that claim a column has a different type than it now has. Fix this by checking during plan startup that Vars at relation scan level match the current relation tuple descriptor. Since at that point we already have at least AccessShareLock, we can be sure the column type will not change underneath us later in the query. However, since a backend's locks do not conflict against itself, there is still a hole for an attacker to exploit: he could try to execute ALTER COLUMN TYPE while a query is in progress in the current backend. Seal that hole by rejecting ALTER TABLE whenever the target relation is already open in the current backend. This is a significant security hole: not only can one trivially crash the backend, but with appropriate misuse of pass-by-reference datatypes it is possible to read out arbitrary locations in the server process's memory, which could allow retrieving database content the user should not be able to see. Our thanks to Jeff Trout for the initial report. Security: CVE-2007-0556
* Repair insufficiently careful type checking for SQL-language functions:Tom Lane2007-02-02
| | | | | | | | | | | | | | | | we should check that the function code returns the claimed result datatype every time we parse the function for execution. Formerly, for simple scalar result types we assumed the creation-time check was sufficient, but this fails if the function selects from a table that's been redefined since then, and even more obviously fails if check_function_bodies had been OFF. This is a significant security hole: not only can one trivially crash the backend, but with appropriate misuse of pass-by-reference datatypes it is possible to read out arbitrary locations in the server process's memory, which could allow retrieving database content the user should not be able to see. Our thanks to Jeff Trout for the initial report. Security: CVE-2007-0555
* Translation updatesPeter Eisentraut2007-01-31
|
* Correct an old logic error in btree page splitting: when considering a splitTom Lane2007-01-27
| | | | | | | | | | | | exactly at the point where we need to insert a new item, the calculation used the wrong size for the "high key" of the new left page. This could lead to choosing an unworkable split, resulting in "PANIC: failed to add item to the left sibling" (or "right sibling") failure. Although this bug has been there a long time, it's very difficult to trigger a failure before 8.2, since there was generally a lot of free space on both sides of a chosen split. In 8.2, where the user-selected fill factor determines how much free space the code tries to leave, an unworkable split is much more likely. Report by Joe Conway, diagnosis and fix by Heikki Linnakangas.
* Back-port changes of Jan 16 and 17 to "revoke" pending fsync requests duringTom Lane2007-01-27
| | | | | | | | | DROP TABLE and DROP DATABASE. Should prevent unexpected "permission denied" failures on Windows, and is cleaner on other platforms too since we no longer have to take it on faith that ENOENT is okay during an fsync attempt. Patched as far back as 8.1; per recent discussion I think we are not going to worry about Windows-specific issues in 8.0 anymore.
* Get pg_utf_mblen(), pg_utf2wchar_with_len(), and utf2ucs() all on the sameTom Lane2007-01-24
| | | | | | | | | | | | | | | | | | | | | page about the maximum UTF8 sequence length we support (4 bytes since 8.1, 3 before that). pg_utf2wchar_with_len never got updated to support 4-byte characters at all, and in any case had a buffer-overrun risk in that it could produce multiple pg_wchars from what mblen claims to be just one UTF8 character. The only reason we don't have a major security hole is that most callers allocate worst-case output buffers; the sole exception in released versions appears to be pre-8.2 iwchareq() (ie, ILIKE), which can be crashed due to zeroing out its return address --- but AFAICS that can't be exploited for anything more than a crash, due to inability to control what gets written there. Per report from James Russell and Michael Fuhr. Pre-8.1 the risk is much less, but I still think pg_utf2wchar_with_len's behavior given an incomplete final character risks buffer overrun, so back-patch that logic change anyway. This patch also makes sure that UTF8 sequences exceeding the supported length (whichever it is) are consistently treated as error cases, rather than being treated like a valid shorter sequence in some places.
* Relax an Assert() that has been found to be too strict in some situationsTom Lane2007-01-24
| | | | | | | involving unions of types having typmods. Variants of the failure are known to occur in 8.1 and up; not sure if it's possible in 8.0 and 7.4, but since the code exists that far back, I'll just patch 'em all. Per report from Brian Hurt.
* Fix autovacuum to avoid leaving non-permanent Xids in non-connectableAlvaro Herrera2007-01-14
| | | | | | | databases. Apply to the 8.1 branch only, as the new 8.2 (and HEAD) coding does not have this problem.
* Fix a performance problem in databases with large numbers of tablesTom Lane2007-01-11
| | | | | | | | | | | (or other types of pg_class entry): the function pgstat_vacuum_tabstat, invoked during VACUUM startup, had runtime proportional to the number of stats table entries times the number of pg_class rows; in other words O(N^2) if the stats collector's information is reasonably complete. Replace list searching with a hash table to bring it back to O(N) behavior. Per report from kim at myemma.com. Back-patch as far as 8.1; 8.0 and before use different coding here.
* Fix regex_fixed_prefix() to cope reasonably well with regex patterns of theTom Lane2007-01-03
| | | | | | | | | | form '^(foo)$'. Before, these could never be optimized into indexscans. The recent changes to make psql and pg_dump generate such patterns (for \d commands and -t and related switches, respectively) therefore represented a big performance hit for people with large pg_class catalogs, as seen in recent gripe from Erik Jones. While at it, be more paranoid about case-sensitivity checking in multibyte encodings, and fix some other corner cases in which a regex might be interpreted too liberally.
* Modify local buffer management to request memory for local buffers in blocksTom Lane2006-12-27
| | | | | | | | | | | of increasing size, instead of one at a time. This reduces the memory management overhead when num_temp_buffers is large: in the previous coding we would actually waste 50% of the space used for temp buffers, because aset.c would round the individual requests up to 16K. Problem noted while studying a performance issue reported by Steven Flatt. Back-patch as far as 8.1 --- older versions used few enough local buffers that the issue isn't significant for them.
* Repair bug #2839: the various ExecReScan functions need to resetTom Lane2006-12-26
| | | | | | | | | ps_TupFromTlist in plan nodes that make use of it. This was being done correctly in join nodes and Result nodes but not in any relation-scan nodes. Bug would lead to bogus results if a set-returning function appeared in the targetlist of a subquery that could be rescanned after partial execution, for example a subquery within EXISTS(). Bug has been around forever :-( ... surprising it wasn't reported before.
* When truncating a relation in-place (eg during VACUUM), do not try to unlinkTom Lane2006-11-20
| | | | | | | | | | | | | any no-longer-needed segments; just truncate them to zero bytes and leave the files in place for possible future re-use. This avoids problems when the segments are re-used due to relation growth shortly after truncation. Before, the bgwriter, and possibly other backends, could still be holding open file references to the old segment files, and would write dirty blocks into those files where they'd disappear from the view of other processes. Back-patch as far as 8.0. I believe the 7.x branches are not vulnerable, because they had no bgwriter, and "blind" writes by other backends would always be done via freshly-opened file references.
* Repair problems with hash indexes that span multiple segments: the hash code'sTom Lane2006-11-19
| | | | | | | | | | | | | | | | | | preference for filling pages out-of-order tends to confuse the sanity checks in md.c, as per report from Balazs Nagy in bug #2737. The fix is to ensure that the smgr-level code always has the same idea of the logical EOF as the hash index code does, by using ReadBuffer(P_NEW) where we are adding a single page to the end of the index, and using smgrextend() to reserve a large batch of pages when creating a new splitpoint. The patch is a bit ugly because it avoids making any changes in md.c, which seems the most prudent approach for a backpatchable beta-period fix. After 8.3 development opens, I'll take a look at a cleaner but more invasive patch, in particular getting rid of the now unnecessary hack to allow reading beyond EOF in mdread(). Backpatch as far as 7.4. The bug likely exists in 7.3 as well, but because of the magnitude of the 7.3-to-7.4 changes in hash, the later-version patch doesn't even begin to apply. Given the other known bugs in the 7.3-era hash code, it does not seem worth trying to develop a separate patch for 7.3.
* Repair two related errors in heap_lock_tuple: it was failing to recognizeTom Lane2006-11-17
| | | | | | | | | cases where we already hold the desired lock "indirectly", either via membership in a MultiXact or because the lock was originally taken by a different subtransaction of the current transaction. These cases must be accounted for to avoid needless deadlocks and/or inappropriate replacement of an exclusive lock with a shared lock. Per report from Clarence Gardner and subsequent investigation.
* Repair bug #2694 concerning an ARRAY[] construct whose inputs are emptyTom Lane2006-11-06
| | | | | | | | | | sub-arrays. Per discussion, if all inputs are empty arrays then result must be an empty array too, whereas a mix of empty and nonempty arrays should (and already did) draw an error. In the back branches, the construct was strict: any NULL input immediately yielded a NULL output; so I left that behavior alone. HEAD was simply ignoring NULL sub-arrays, which doesn't seem very sensible. For lack of a better idea it now treats NULL sub-arrays the same as empty ones.
* Fix recently-identified PITR recovery hazard: the base backup could containTom Lane2006-11-05
| | | | | | | | | | | | | stale relcache init files (pg_internal.init), and there is no mechanism for updating them during WAL replay. Easiest solution is just to delete the init files at conclusion of startup, and let the first backend started in each database take care of rebuilding the init file. Simon Riggs and Tom Lane. Back-patched to 8.1. Arguably this should be fixed in 8.0 too, but it would require significantly more code since 8.0 has no handy startup-time scan of pg_database to piggyback on. Manual solution of the problem is possible in 8.0 (just delete the pg_internal.init files before starting WAL replay), so that may be a sufficient answer.
* Fix "failed to re-find parent key" btree VACUUM failure by tweakingTom Lane2006-11-01
| | | | | | | | | _bt_pagedel to recover from the failure: just search the whole parent level if searching to the right fails. This does nothing for the underlying problem that index keys became out-of-order in the grandparent level. However, we believe that there is no other consequence worse than slightly inefficient searching, so this narrow patch seems like the safest solution for the back branches.
* Back-patch second version of AIX getaddrinfo fix.Tom Lane2006-10-20
|
* Work around reported problem that AIX's getaddrinfo() doesn't seem to zeroTom Lane2006-10-19
| | | | | | | sin_port in the returned IP address struct when servname is NULL. This has been observed to cause failure to bind the stats collection socket, and could perhaps cause other issues too. Per reports from Brad Nicholson and Chris Browne.
* Fix infinite sleep and failes of send in Win32.Teodor Sigaev2006-10-13
| | | | | | | | | | | | | | | 1) pgwin32_waitforsinglesocket(): WaitForMultipleObjectsEx now called with finite timeout (100ms) in case of FP_WRITE and UDP socket. If timeout occurs then pgwin32_waitforsinglesocket() tries to write empty packet goes to WaitForMultipleObjectsEx again. 2) pgwin32_send(): add loop around WSASend and pgwin32_waitforsinglesocket(). The reason is: for overlapped socket, 'ok' result from pgwin32_waitforsinglesocket() isn't guarantee that socket is still free, it can become busy again and following WSASend call will fail with WSAEWOULDBLOCK error. See http://archives.postgresql.org/pgsql-hackers/2006-10/msg00561.php
* Fix mishandling of after-trigger state when a SQL function returns multipleTom Lane2006-10-12
| | | | | | | | | | rows --- if the surrounding query queued any trigger events between the rows, the events would be fired at the wrong time, leading to bizarre behavior. Per report from Merlin Moncure. This is a simple patch that should solve the problem fully in the back branches, but in HEAD we also need to consider the possibility of queries with RETURNING clauses. Will look into a fix for that separately.
* Repair incorrect check for coercion of unknown literal to ANYARRAY, a bugTom Lane2006-10-11
| | | | | | | | | | | | I introduced in 7.4.1 :-(. It's correct to allow unknown to be coerced to ANY or ANYELEMENT, since it's a real-enough data type, but it most certainly isn't an array datatype. This can cause a backend crash but AFAICT is not exploitable as a security hole. Per report from Michael Fuhr. Note: as fixed in HEAD, this changes a constant in the pg_stats view, resulting in a change in the expected regression outputs. The back-branch patches have been hacked to avoid that, so that pre-existing installations won't start failing their regression tests.
* CREATE TABLE ... LIKE ... should mark the columns it creates withTom Lane2006-10-11
| | | | | | | | attislocal = true, since they are not really inherited but merely copied from the original table. I'm not sure if there are any cases where it makes a real difference given the existing uses of the flag, but wrong is wrong. This was fixed in passing in HEAD by the LIKE INCLUDING CONSTRAINTS patch, but never back-patched.
* Fix string_to_array() to correctly handle the case where there areTom Lane2006-10-07
| | | | | | | | | | | overlapping possible matches for the separator string, such as string_to_array('123xx456xxx789', 'xx'). Also, revise the logic of replace(), split_part(), and string_to_array() to avoid O(N^2) work from redundant searches and conversions to pg_wchar format when there are N matches to the separator string. Backpatched the full patch as far as 8.0. 7.4 also has the bug, but the code has diverged a lot, so I just went for a quick-and-dirty fix of the bug itself in that branch.
* Fix SysCacheGetAttr() to handle the case where the specified syscache has notTom Lane2006-10-06
| | | | | | | | | | | been initialized yet. This can happen because there are code paths that call SysCacheGetAttr() on a tuple originally fetched from a different syscache (hopefully on the same catalog) than the one specified in the call. It doesn't seem useful or robust to try to prevent that from happening, so just improve the function to cope instead. Per bug#2678 from Jeff Trout. The specific example shown by Jeff is new in 8.1, but to be on the safe side I'm backpatching 8.0 as well. We could patch 7.x similarly but I think that's probably overkill, given the lack of evidence of old bugs of this ilk.
* Fix overly enthusiastic Assert introduced in 8.1: it's expecting aTom Lane2006-10-01
| | | | | CaseTestExpr, but forgot that the optimizer is sometimes able to replace CaseTestExpr by Const.
* Backpatch to 8.1.X fix for to_timestamp() where "PM/AM" specificationBruce Momjian2006-09-04
| | | | was eating too much user input, producing incorrect results.
* Clean up rather sloppy fix in HEAD for the ancient bug that CREATE CONVERSIONTom Lane2006-08-31
| | | | | didn't create a dependency from the new conversion to its schema. Back-patch to all supported releases.
* Fix mistypingTeodor Sigaev2006-08-29
|
* In new "invalid byte sequence" error hint, call it "error", notBruce Momjian2006-08-22
| | | | "failure".
* Add hint for "invalid byte sequence for encoding" error message,Bruce Momjian2006-08-22
| | | | suggesting review of client_encoding.
* Fix core dump in duration logging for a V3-protocol Execute messageTom Lane2006-08-13
| | | | | | when what's being executed is a COMMIT or ROLLBACK. Per report from Sergey Koposov. Backpatch to 8.1; 8.0 and before don't have the bug due to lack of any logging at all here.
* Round microseconds on setitimer upwards.Bruce Momjian2006-08-09
|
* On Win32, make minimum setitimer() sleep be 1ms, so sleeps < 1ms aren'tBruce Momjian2006-08-09
| | | | | | rounded down to zero. Backpatch to 8.1.X.
* Fix statement_timeout on Win32 so that it properly treats micro-secondsBruce Momjian2006-08-09
| | | | | | | | as micro-seconds, rather than as 100 microseconds, as it does now. This actually fixes all setitimer calls on Win32, but statement_timeout is the most visible fix. Backpatch to 8.1.X. 8.0 works as documented.
* prevent multiplexing Windows kernel event objects we listen for across ↵Andrew Dunstan2006-07-29
| | | | various sockets - should fix the occasional stats test regression failures we see.
* Fix oversight in sizing of shared buffer lookup hashtable. BecauseTom Lane2006-07-23
| | | | | | | | | BufferAlloc tries to insert a new mapping entry before deleting the old one for a buffer, we have a transient need for more than NBuffers entries --- one more in 8.1, and as many as NUM_BUFFER_PARTITIONS more in CVS HEAD. In theory this could lead to an "out of shared memory" failure if shmem had already been completely claimed by the time the extra entries were needed.
* Hmm, seems --disable-spinlocks has been broken for awhile and nobodyTom Lane2006-07-22
| | | | | noticed. Fix SpinlockSemas() to report the correct count considering that PG 8.1 adds a spinlock to each shared-buffer header.
* Don't try to truncate multixact SLRU files in checkpoints done during xlogTom Lane2006-07-20
| | | | | | | | | | | recovery. In the first place, it doesn't work because slru's latest_page_number isn't set up yet (this is why we've been hearing reports of strange "apparent wraparound" log messages during crash recovery, but only from people who'd managed to advance their next-mxact counters some considerable distance from 0). In the second place, it seems a bit unwise to be throwing away data during crash recovery anwyway. This latter consideration convinces me to just disable truncation during recovery, rather than computing latest_page_number and pushing ahead.
* Ensure that we retry rather than erroring out when send() or recv() returnTom Lane2006-07-16
| | | | | | | | | | | | EINTR; the stats code was failing to do this and so were a couple of places in the postmaster. The stats code assumed that recv() could not return EINTR if a preceding select() showed the socket to be read-ready, but this is demonstrably false with our Windows implementation of recv(), and it may not be the case on all Unix variants either. I think this explains the intermittent stats regression test failures we've been seeing, as well as reports of stats collector instability under high load on Windows. Backpatch as far as 8.0.
* Fix ALTER TABLE to check pre-existing NOT NULL constraints when rewritingTom Lane2006-07-10
| | | | | | a table. Otherwise a USING clause that yields NULL can leave the table violating its constraint (possibly there are other cases too). Per report from Alexander Pravking.
* Fix typo.Tom Lane2006-06-27
|
* Clamp last_anl_tuples to n_live_tuples, in case we vacuum a table withoutAlvaro Herrera2006-06-27
| | | | | | | | analyzing, so that future analyze threshold calculations don't get confused. Also, make sure we correctly track the decrease of live tuples cause by deletes. Per report from Dylan Hansen, patches by Tom Lane and me.
* Tweak dynahash.c to avoid wasting memory space in non-shared hash tables.Tom Lane2006-06-25
| | | | | | | | palloc() will normally round allocation requests up to the next power of 2, so make dynahash choose allocation sizes that are as close to a power of 2 as possible. Back-patch to 8.1 --- the problem exists further back, but a much larger patch would be needed and it doesn't seem worth taking any risks.
* pg_stop_backup was calling XLogArchiveNotify() twice for the newly createdTom Lane2006-06-22
| | | | | backup history file. Bug introduced by the 8.1 change to make pg_stop_backup delete older history files. Per report from Masao Fujii.
* Disallow aggregate functions in UPDATE commands (unless within a sub-SELECT).Tom Lane2006-06-21
| | | | | | | | This is disallowed by the SQL spec because it doesn't have any very sensible interpretation. Historically Postgres has allowed it but behaved strangely. As of PG 8.1 a server crash is possible if the MIN/MAX index optimization gets applied; rather than try to "fix" that, it seems best to just enforce the spec restriction. Per report from Josh Drake and Alvaro Herrera.
* Avoid use of C commment inside C comment from recent Win32 int overflow patch.Bruce Momjian2006-06-12
|
* Win32 can't catch the exception thrown by INT_MIN / -1 or INT_MIN * -1,Bruce Momjian2006-06-12
| | | | | | | so on that platform we test for those before the computation and throw an "out of range" error. Backpatch to 8.1.X.
generated by cgit v1.2.3 (git 2.25.1) at 2025-08-03 15:08:05 +0000