aboutsummaryrefslogtreecommitdiff
path: root/src
Commit message (Collapse)AuthorAge
...
* 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 oversight in coding of _bt_start_vacuum: we can't assume that the LWLockTom Lane2007-03-30
| | | | | | | will be released by transaction abort before _bt_end_vacuum gets called. If either of these "can't happen" errors actually happened, we'd freeze up trying to acquire an already-held lock. Latest word is that this does not explain Martin Pitt's trouble report, but it still looks like a bug.
* Fix typo, ensable -> enable, per Steve Gieseking.Tom Lane2007-03-27
|
* Fix pg_wchar_table's maxmblen field of EUC_CN, EUC_TW, MULE_INTERNALTatsuo Ishii2007-03-26
| | | | and GB18030. patches from ITAGAKI Takahiro.
* Fix 8.2 breakage of domains over array types, and add a regression test caseTom Lane2007-03-19
| | | | to cover it. Per report from Anton Pikhteryev.
* 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.
* Arrange to install a "posixrules" entry in our timezone database, so thatTom Lane2007-03-14
| | | | | | | | | | | | | POSIX-style timezone specs that don't exactly match any database entry will be treated as having correct USA DST rules. Also, document that this can be changed if you want to use some other DST rules with a POSIX zone spec. We could consider changing localtime.c's TZDEFRULESTRING, but since that facility can only deal with one DST transition rule, it seems fairly useless now; might as well just plan to override it using a "posixrules" entry. Backpatch as far as 8.0. There isn't much we can do in 7.x ... either your libc gets it right, or it doesn't.
* 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.
* Remove unsafe calling of WSAStartup and WSACleanup from DllMain. Move theMagnus Hagander2007-03-08
| | | | | | | inline cleanup call around so it will be called in the right order, and be called on errors. Per report from Tokuharu Yuzawa.
* Fix vac_update_relstats to ensure it always sends a relcache inval message,Tom Lane2007-03-08
| | | | | | | | even if none of the fields in the pg_class row change. This behavior is necessary to ensure other backends flush rd_targblock values that might point to truncated-away pages. We got this right pre-8.2 but it was broken by overoptimistic change to not write out the pg_class row if unchanged. Per report from Pavan Deolasee.
* Fix oversight in original coding of inline_function(): sinceTom Lane2007-03-06
| | | | | | | | | | | | | | check_sql_fn_retval allows binary-compatibility cases, the expression extracted from an inline-able SQL function might have a type that is only binary-compatible with the declared function result type. To avoid possibly changing the semantics of the expression, we should insert a RelabelType node in such cases. This has only been shown to have bad consequences in recent 8.1 and up releases, but I suspect there may be failure cases in the older branches too, so patch it all the way back. Per bug #3116 from Greg Mullane. Along the way, fix an omission in eval_const_expressions_mutator: it failed to copy the relabelformat field when processing a RelabelType. No known observable failures from this, but it definitely isn't intended behavior.
* Fix miscalculation of stats collector's write delay, introduced in revision ↵Tom Lane2007-03-01
| | | | 1.117.
* Fix markQueryForLocking() to work correctly in the presence of nested views.Tom Lane2007-03-01
| | | | | It has been wrong for this case since it was first written for 7.1 :-( Per report from Pavel Hanák.
* Backported bug fix for #2956.Michael Meskes2007-02-27
|
* Fix pg_dump on win32 to properly dump files larger than 2Gb when usingMagnus Hagander2007-02-19
| | | | binary dump formats.
* Fix portal management code to support non-default command completion tags forTom Lane2007-02-18
| | | | | | portals using PORTAL_UTIL_SELECT strategy. This is currently significant only for FETCH queries, which are supposed to include a count in the tag. Seems it's been broken since 7.4, but nobody noticed before Knut Lehre.
* 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.
generated by cgit v1.2.3 (git 2.25.1) at 2025-06-20 07:18:38 +0000