aboutsummaryrefslogtreecommitdiff
path: root/src
Commit message (Collapse)AuthorAge
...
* Adjust the definition of is_pushed_down so that it's always true for INNERTom Lane2007-02-16
| | | | | | | | | JOIN quals, just like WHERE quals, even if they reference every one of the join's relations. Now that we can reorder outer and inner joins, it's possible for such a qual to end up being assigned to an outer join plan node, and we mustn't have it treated as a join qual rather than a filter qual for the node. (If it were, the join could produce null-extended rows that it shouldn't.) Per bug report from Pelle Johansson.
* Fix another problem in 8.2 changes that allowed "one-time" qual conditions toTom Lane2007-02-16
| | | | | | | be checked at plan levels below the top; namely, we have to allow for Result nodes inserted just above a nestloop inner indexscan. Should think about using the general Param mechanism to pass down outer-relation variables, but for the moment we need a back-patchable solution. Per report from Phil Frost.
* Restructure code that is responsible for ensuring that clauseless joins areTom Lane2007-02-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | considered when it is necessary to do so because of a join-order restriction (that is, an outer-join or IN-subselect construct). The former coding was a bit ad-hoc and inconsistent, and it missed some cases, as exposed by Mario Weilguni's recent bug report. His specific problem was that an IN could be turned into a "clauseless" join due to constant-propagation removing the IN's joinclause, and if the IN's subselect involved more than one relation and there was more than one such IN linking to the same upper relation, then the only valid join orders involve "bushy" plans but we would fail to consider the specific paths needed to get there. (See the example case added to the join regression test.) On examining the code I wonder if there weren't some other problem cases too; in particular it seems that GEQO was defending against a different set of corner cases than the main planner was. There was also an efficiency problem, in that when we did realize we needed a clauseless join because of an IN, we'd consider clauseless joins against every other relation whether this was sensible or not. It seems a better design is to use the outer-join and in-clause lists as a backup heuristic, just as the rule of joining only where there are joinclauses is a heuristic: we'll join two relations if they have a usable joinclause *or* this might be necessary to satisfy an outer-join or IN-clause join order restriction. I refactored the code to have just one place considering this instead of three, and made sure that it covered all the cases that any of them had been considering. Backpatch as far as 8.1 (which has only the IN-clause form of the disease). By rights 8.0 and 7.4 should have the bug too, but they accidentally fail to fail, because the joininfo structure used in those releases preserves some memory of there having once been a joinclause between the inner and outer sides of an IN, and so it leads the code in the right direction anyway. I'll be conservative and not touch them.
* Repair oversight in 8.2 change that improved the handling of "pseudoconstant"Tom Lane2007-02-15
| | | | | | | | | WHERE clauses. createplan.c is now willing to stick a gating Result node almost anywhere in the plan tree, and in particular one can wind up directly underneath a MergeJoin node. This means it had better be willing to handle Mark/Restore. Fortunately, that's trivial in such cases, since we can just pass off the call to the input node (which the planner has previously ensured can handle Mark/Restore). Per report from Phil Frost.
* Disallow committing a prepared transaction unless we are in the same databaseTom Lane2007-02-13
| | | | | it was executed in. Someday it might be nice to allow cross-DB commits, but work would be needed in NOTIFY and perhaps other places. Per Heikki.
* Repair bug in 8.2's new logic for planning outer joins: we have to allow joinsTom Lane2007-02-13
| | | | | | | | that overlap an outer join's min_righthand but aren't fully contained in it, to support joining within the RHS after having performed an outer join that can commute with this one. Aside from the direct fix in make_join_rel(), fix has_join_restriction() and GEQO's desirable_join() to consider this possibility. Per report from Ian Harding.
* Fix for early log messages during postmaster startup getting lost whenMagnus Hagander2007-02-11
| | | | | | | | running as a service on Win32. Per report from Harald Armin Massa. Backpatch to 8.2.
* Fix bug when localized to_char() day or month names were incorectlyBruce Momjian2007-02-08
| | | | | | | | trnasformed to lower or upper string. Backpatch to 8.2.X. Pavel Stehule
* Fix an ancient logic error in plpgsql's exec_stmt_block: it thought it couldTom Lane2007-02-08
| | | | | | | | | | | | | | | | | | | get away with not (re)initializing a local variable if the variable is marked "isconst" and not "isnull". Unfortunately it makes this decision after having already freed the old value, meaning that something like for i in 1..10 loop declare c constant text := 'hi there'; leads to subsequent accesses to freed memory, and hence probably crashes. (In particular, this is why Asif Ali Rehman's bug leads to crash and not just an unexpectedly-NULL value for SQLERRM: SQLERRM is marked CONSTANT and so triggers this error.) The whole thing seems wrong on its face anyway: CONSTANT means that you can't change the variable inside the block, not that the initializer expression is guaranteed not to change value across successive block entries. Hence, remove the "optimization" instead of trying to fix it.
* Rearrange use of plpgsql_add_initdatums() so that only the parsing of aTom Lane2007-02-08
| | | | | | | | | | | | | | DECLARE section needs to know about it. Formerly, everyplace besides DECLARE that created variables needed to do "plpgsql_add_initdatums(NULL)" to prevent those variables from being sucked up as part of a subsequent DECLARE block. This is obviously error-prone, and in fact the SQLSTATE/SQLERRM patch had failed to do it for those two variables, leading to the bug recently exhibited by Asif Ali Rehman: a DECLARE within an exception handler tried to reinitialize SQLERRM. Although the SQLSTATE/SQLERRM patch isn't in any pre-8.1 branches, and so I can't point to a demonstrable failure there, it seems wise to back-patch this into the older branches anyway, just to keep the logic similar to HEAD.
* 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.