aboutsummaryrefslogtreecommitdiff
path: root/src
Commit message (Collapse)AuthorAge
...
* This patch fixes shared_preload_libraries on Windows hosts. It forcesBruce Momjian2007-02-08
| | | | | | | | each backend to re-load all shared_preload_libraries. Backpatch to 8.2.X. Korry Douglas
* Fix PG_VERSION_NUM too.Tom Lane2007-02-07
|
* Stamp releases 8.2.3, 8.1.8, 8.0.12. No release notes yet.Bruce Momjian2007-02-07
|
* Fix an error in the original coding of holdable cursors: PersistHoldablePortalTom Lane2007-02-06
| | | | | | | | | | | thought that it didn't have to reposition the underlying tuplestore if the portal is atEnd. But this is not so, because tuplestores have separate read and write cursors ... and the read cursor hasn't moved from the start. This mistake explains bug #2970 from William Zhang. Note: the coding here is pretty inefficient, but given that no one has noticed this bug until now, I'd say hardly anyone uses the case where the cursor has been advanced before being persisted. So maybe it's not worth worrying about.
* 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.
* Backported regression test changes from HEAD so the buildfarm hopefully gets ↵Michael Meskes2007-02-06
| | | | green again.
* Backported va_list handling cleanupMichael Meskes2007-02-06
|
* Fix a performance regression in 8.2: optimization of MIN/MAX into indexscansTom Lane2007-02-06
| | | | | | | had stopped working for tables buried inside views or sub-selects. This is because I had gotten rid of the simplify_jointree() preprocessing step, and optimize_minmax_aggregates() wasn't smart enough to deal with a non-canonical FromExpr. Per gripe from Bill Howe.
* Pass modern COPY syntax to backend, since copy (query) does not accept old ↵Andrew Dunstan2007-02-05
| | | | syntax. Per complaint from Michael Fuhr.
* Don't MAXALIGN in the checks to decide whether a tuple is over TOAST'sTom Lane2007-02-04
| | | | | | | | | | | | | | | | | | | | | | | | | | threshold for tuple length. On 4-byte-MAXALIGN machines, the toast code creates tuples that have t_len exactly TOAST_TUPLE_THRESHOLD ... but this number is not itself maxaligned, so if heap_insert maxaligns t_len before comparing to TOAST_TUPLE_THRESHOLD, it'll uselessly recurse back to tuptoaster.c, wasting cycles. (It turns out that this does not happen on 8-byte-MAXALIGN machines, because for them the outer MAXALIGN in the TOAST_MAX_CHUNK_SIZE macro reduces TOAST_MAX_CHUNK_SIZE so that toast tuples will be less than TOAST_TUPLE_THRESHOLD in size. That MAXALIGN is really incorrect, but we can't remove it now, see below.) There isn't any particular value in maxaligning before comparing to the thresholds, so just don't do that, which saves a small number of cycles in itself. These numbers should be rejiggered to minimize wasted space on toast-relation pages, but we can't do that in the back branches because changing TOAST_MAX_CHUNK_SIZE would force an initdb (by changing the contents of toast tables). We can move the toast decision thresholds a bit, though, which is what this patch effectively does. Thanks to Pavan Deolasee for discovering the unintended recursion. Back-patch into 8.2, but not further, pending more testing. (HEAD is about to get a further patch modifying the thresholds, so it won't help much for testing this form of the patch.)
* Stamp release 8.2.2.REL8_2_2Tom Lane2007-02-02
| | | | Security: CVE-2007-0555, CVE-2007-0556
* 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
* Fix plpgsql so that when a local variable has no initial-value expression,Tom Lane2007-02-01
| | | | | an error will be thrown correctly if the variable is of a NOT NULL domain. Report and almost-correct fix from Sergiy Vyshnevetskiy (bug #2948).
* Translation updatesPeter Eisentraut2007-01-31
|
* Repair oversights in the mechanism used to store compiled plpgsql functions.Tom Lane2007-01-30
| | | | | | | | | | | | | The original coding failed (tried to access deallocated memory) if there were two active call sites (fn_extra pointers) for the same function and the function definition was updated. Also, if an update of a recursive function was detected upon nested entry to the function, the existing compiled version was summarily deallocated, resulting in crash upon return to the outer instance. Problem observed while studying a bug report from Sergiy Vyshnevetskiy. Bug does not exist before 8.1 since older versions just leaked the memory of obsoleted compiled functions, rather than trying to reclaim it.
* Add SPI_push/SPI_pop calls so that datatype input and output functions calledTom Lane2007-01-30
| | | | | | | | | by plpgsql can themselves use SPI --- possibly indirectly, as in the case of domain_in() invoking plpgsql functions in a domain check constraint. Per bug #2945 from Sergiy Vyshnevetskiy. Somewhat arbitrarily, I've chosen to back-patch this as far as 8.0. Given the lack of prior complaints, it doesn't seem critical for 7.x.
* Clarify paramater handling for pg_get_serial_sequence().Bruce Momjian2007-01-30
|
* Repair oversight in creation of "append relations": we should set upTom Lane2007-01-28
| | | | | rel->tuples as well as rel->rows, since some estimation functions expect both to be valid in every baserel. Per report from Dave Dutcher.
* Fix up plpgsql's "simple expression" evaluation mechanism so that it behavesTom Lane2007-01-28
| | | | | | | | | | | | | | safely in the presence of subtransactions. To ensure that any ExprContext shutdown callbacks are called at the right times, we have to have a separate EState for each level of subtransaction. Per "TupleDesc reference leak" bug report from Stefan Kaltenbrunner. Although I'm convinced the code is wrong as far back as 8.0, it doesn't seem that there are any ways for the problem to really manifest before 8.2: AFAICS, 8.0 and 8.1 only use the ExprContextCallback mechanism to handle set-returning functions, which cannot usefully be executed in a "simple expression" anyway. Hence, no backpatch before 8.2 --- the risk of unforeseen breakage seems to outweigh the chance of fixing something.
* Dept of second thoughts: the IQ of estimate_array_length() needs to beTom Lane2007-01-28
| | | | | kept on par with that of scalararraysel(), else estimates that should track might not. Hence teach it about binary-compatible cases, too.
* Fix scalararraysel() to cope with binary-compatible cases, such as text[]Tom Lane2007-01-28
| | | | | | versus varchar[]. This oversight probably explains Ryan Holmes' recent complaint --- he was getting a generic selectivity estimate instead of anything intelligent.
* 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.
* On Windows, use pgwin32_waitforsinglesocket() instead of select() to wait forTom Lane2007-01-26
| | | | | | | | | | input in the stats collector. Our select() emulation is apparently buggy for UDP sockets :-(. This should resolve problems with stats collection (and hence autovacuum) failing under more than minimal load. Diagnosis and patch by Magnus Hagander. Patch probably needs to be back-ported to 8.1 and 8.0, but first let's see if it makes the buildfarm happy...
* Properly detoast access to bytea field pg_trigger.tgargs. Old codeBruce Momjian2007-01-25
| | | | | | might cause server crash. Backpatch to 8.2.X.
* 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.
* Add documentation of memory and time units to postgresql.conf.Bruce Momjian2007-01-20
| | | | Backpatch to 8.2.X for new initdbs.
* Fix incorrect permissions check in information_schema.key_column_usage view:Tom Lane2007-01-16
| | | | | | | | | | it was checking a pg_constraint OID instead of pg_class OID, resulting in "relation with OID nnnnn does not exist" failures for anyone who wasn't owner of the table being examined. Per bug #2848 from Laurence Rowe. Note: for existing 8.2 installations a simple version update won't fix this; the easiest fix is to CREATE OR REPLACE this view with the corrected definition.
* Fix handling of CC (century) format spec in to_date/to_char. According toTom Lane2007-01-12
| | | | | | | | standard convention the 21st century runs from 2001-2100, not 2000-2099, so make it work like that. Per bug #2885 from Akio Iwaasa. Backpatch to 8.2, but no further, since this is really a definitional change; users of older branches are probably more interested in stability.
* 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.
* Allow Borland CC to compile libpq and psql.Bruce Momjian2007-01-11
| | | | | | Backpatch to 8.2.X. L Bayuk
* Tweak joinlist creation to avoid generating useless one-element subproblemsTom Lane2007-01-08
| | | | | | | | | | when collapsing of JOIN trees is stopped by join_collapse_limit. For instance a list of 11 LEFT JOINs with limit 8 now produces something like ((1 2 3 4 5 6 7 8) 9 10 11 12) instead of (((1 2 3 4 5 6 7 8) (9)) 10 11 12) The latter structure is really only required for a FULL JOIN. Noted while studying an example from Shane Ambler.
* Remove cost_hashjoin's very ancient hack to discourage (once, entirely forbid)Tom Lane2007-01-08
| | | | | | | | | | | hash joins with the estimated-larger relation on the inside. There are several cases where doing that makes perfect sense, and in cases where it doesn't, the regular cost computation really ought to be able to figure that out. Make some marginal tweaks in said computation to try to get results approximating reality a bit better. Per an example from Shane Ambler. Also, fix an oversight in the original patch to add seq_page_cost: the costs of spilling a hash join to disk should be scaled by seq_page_cost.
* Fix oversight in handling of row-comparison index keys: if the row comparisonTom Lane2007-01-07
| | | | | | | | | | | doesn't exactly match the index, we may have to change our initial positioning strategy. For example, given an index on (f1,f2,f3) and a WHERE condition "ROW(f1,f3) > ROW(2,3)", the code extracted the initial-positioning condition "f1 > 2", which is wrong ... it has to be "f1 >= 2", else some rows matching the WHERE condition may fail to be returned. Applying patch to 8.2 only --- I'll fix it in HEAD later as part of the planned index improvements (reverse-sort and NULLS FIRST/LAST work).
* Fix filtered_base_yylex() to save and restore base_yylval and base_yyllocTom Lane2007-01-06
| | | | | properly when doing a lookahead. The lack of this was causing various interesting misbehaviors when one tries to use "with" as a plain identifier.
* Stamp release 8.2.1. Update FAQs.Bruce Momjian2007-01-05
|
* Tweak pg_dumpall to add GRANT CONNECT ON DATABASE ... TO PUBLIC when dumpingTom Lane2007-01-04
| | | | | | database privileges from a pre-8.2 server. This ensures that the reloaded database will maintain the same behavior it had in the previous installation, ie, everybody has connect privilege. Per gripe from L Bayuk.
* Fix erroneous implementation of -s in postmaster.c (the switch doesn't takeTom Lane2007-01-04
| | | | | | an optarg). Add some comments noting that code in three different files has to be kept in sync. Fix erroneous description of -S switch (it sets work_mem not silent_mode), and do some light copy-editing elsewhere in postgres-ref.
* 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.
* Add a defense to prevent core dumps if 8.2 version of rank_cd() is used withTom Lane2006-12-28
| | | | | | | | the 8.1 SQL function definition for it. Per report from Rajesh Kumar Mallah, such a DBA error doesn't seem at all improbable, and the cost of checking for it is not very high compared to the cost of running this function. (It would have been better to change the C name of the function so it wouldn't be called by the old SQL definition, but it's too late for that now in the 8.2 branch.)
* Revert exports.list change pending closer study.Tom Lane2006-12-28
|
* Use a more backward-compatible syntax for exports.list on Linux.Tom Lane2006-12-27
| | | | Per Thorkil Olesen.
* 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.
* Print combining characters (those reported as having zero width byTom Lane2006-12-27
| | | | | | PQdsplen()) normally, instead of replacing them by \uXXXX sequences. Assume that they in fact occupy zero screen space for formatting purposes. Per gripe from Michael Fuhr and ensuing discussion.
* Fix failure due to accessing an already-freed tuple descriptor in a planTom Lane2006-12-26
| | | | | | | | | | | | involving HashAggregate over SubqueryScan (this is the known case, there may well be more). The bug is only latent in releases before 8.2 since they didn't try to access tupletable slots' descriptors during ExecDropTupleTable. The least bogus fix seems to be to make subqueries share the parent query's memory context, so that tupdescs they create will have the same lifespan as those of the parent query. There are comments in the code envisioning going even further by not having a separate child EState at all, but that will require rethinking executor access to range tables, which I don't want to tackle right now. Per bug report from Jean-Pierre Pelletier.
* 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.
* Repair bug #2836: SPI_execute_plan returned zero if none of the querytreesTom Lane2006-12-26
| | | | | | | | | were marked canSetTag. While it's certainly correct to return the result of the last one that is marked canSetTag, it's less clear what to do when none of them are. Since plpgsql will complain if zero is returned, the 8.2.0 behavior isn't good. I've fixed it to restore the prior behavior of returning the physically last query's result code when there are no canSetTag queries.
* Make HISTCONTROL=ignoredups work again (broken by misordering ofTom Lane2006-12-24
| | | | operations during recent code refactoring). Per bug #2840 from Ned Crigler.
generated by cgit v1.2.3 (git 2.25.1) at 2025-08-03 17:09:52 +0000