aboutsummaryrefslogtreecommitdiff
path: root/src
Commit message (Collapse)AuthorAge
...
* Mark to_number() and the numeric-type variants of to_char() as stable, notTom Lane2006-11-28
| | | | | | immutable, because their results depend on lc_numeric; this is a longstanding oversight. We cannot force initdb for this in the back branches, but we can at least provide correct catalog entries for future installations.
* Fix psql's \copy command to ensure that it cycles libpq back to the idle stateTom Lane2006-11-24
| | | | | | | | | (in particular, causing the ReadyForQuery message to be eaten) before returning from do_copy. The only known consequence of failing to do so is that get_prompt might show a wrong result for the %x transaction status escape, as reported by Bernd Helmle; but it's possible there are other issues. Back-patch as far as 7.4, the oldest version supporting %x.
* Fix 1-byte buffer overrun when OID exceeds 1 billion. This probably can'tTom Lane2006-11-22
| | | | | | cause any serious harm in normal cases, but if you have gcc buffer overrun checking turned on, that will notice. Found by Jack Orenstein. Problem was already fixed in CVS HEAD.
* 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 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 "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.
* 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 psql \d commands to behave properly when a pattern using regex | is given.Tom Lane2006-10-10
| | | | | | | Formerly they'd emit '^foo|bar$' which is wrong because the anchors are parsed as part of the alternatives; must emit '^(foo|bar)$' to get expected behavior. Same as bug found previously in similar_escape(). Already fixed in HEAD, this is just back-porting the part of that patch that was a bug fix.
* Update libpq.rc for 7.3.16 and 7.4.14. Later releases use libpq.rc.in,Bruce Momjian2006-10-10
| | | | which was already updated.
* Stamp releases 7.3.16, 7.4.14, 8.0.9, and 8.1.5.Bruce Momjian2006-10-09
|
* Fix back-branch pg_regress scripts to try the "canonical" expected file if weTom Lane2006-10-09
| | | | | | | tried a variant file from resultmap and it didn't match. This is already done in HEAD's C-code version, and is needed because OpenBSD has recently migrated to a more standard handling of float underflow --- see buildfarm results from emu.
* Fix ancient oversight in psql's \d pattern processing code: when seeing twoTom Lane2006-10-07
| | | | | | quote chars inside quote marks, should emit one quote *and stay in inquotes mode*. No doubt the lack of reports of this have something to do with the poor documentation of the feature ...
* 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.
* 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
|
* Do not use already free'ed errmsg, bug found by Joachim WielandMichael Meskes2006-06-19
| | | | <joachim.wieland@credativ.de>
* Fixed two memory leaks in ecpglib.Michael Meskes2006-06-06
|
* Fix copy-and-pasteo in Russian translation: message complaining aboutTom Lane2006-06-03
| | | | | HAVE_INT64_TIMESTAMP was mentioning PG_CONTROL_VERSION instead. Victor Snezhko
* Pre-8.0 branches need to cope with possibility that the system libc knowsTom Lane2006-06-01
| | | | | about the recent changes in US DST law. Add a variant horology file, so that either the old or new rules will be considered valid test results.
* Stamp releases 7.3.15, 7.4.13, and 8.0.8.Bruce Momjian2006-05-21
|
* Modify libpq's string-escaping routines to be aware of encoding considerationsTom Lane2006-05-21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | and standard_conforming_strings. The encoding changes are needed for proper escaping in multibyte encodings, as per the SQL-injection vulnerabilities noted in CVE-2006-2313 and CVE-2006-2314. Concurrent fixes are being applied to the server to ensure that it rejects queries that may have been corrupted by attempted SQL injection, but this merely guarantees that unpatched clients will fail rather than allow injection. An actual fix requires changing the client-side code. While at it we have also fixed these routines to understand about standard_conforming_strings, so that the upcoming changeover to SQL-spec string syntax can be somewhat transparent to client code. Since the existing API of PQescapeString and PQescapeBytea provides no way to inform them which settings are in use, these functions are now deprecated in favor of new functions PQescapeStringConn and PQescapeByteaConn. The new functions take the PGconn to which the string will be sent as an additional parameter, and look inside the connection structure to determine what to do. So as to provide some functionality for clients using the old functions, libpq stores the latest encoding and standard_conforming_strings values received from the backend in static variables, and the old functions consult these variables. This will work reliably in clients using only one Postgres connection at a time, or even multiple connections if they all use the same encoding and string syntax settings; which should cover many practical scenarios. Clients that use homebrew escaping methods, such as PHP's addslashes() function or even hardwired regexp substitution, will require extra effort to fix :-(. It is strongly recommended that such code be replaced by use of PQescapeStringConn/PQescapeByteaConn if at all feasible.
* Add a new GUC parameter backslash_quote, which determines whether the SQLTom Lane2006-05-21
| | | | | | | | | | | | | | | | | parser will allow "\'" to be used to represent a literal quote mark. The "\'" representation has been deprecated for some time in favor of the SQL-standard representation "''" (two single quote marks), but it has been used often enough that just disallowing it immediately won't do. Hence backslash_quote allows the settings "on", "off", and "safe_encoding", the last meaning to allow "\'" only if client_encoding is a valid server encoding. That is now the default, and the reason is that in encodings such as SJIS that allow 0x5c (ASCII backslash) to be the last byte of a multibyte character, accepting "\'" allows SQL-injection attacks as per CVE-2006-2314 (further details will be published after release). The "on" setting is available for backward compatibility, but it must not be used with clients that are exposed to untrusted input. Thanks to Akio Ishida and Yasuo Ohgaki for identifying this security issue.
* Change the backend to reject strings containing invalidly-encoded multibyteTom Lane2006-05-21
| | | | | | | | | | | | | | | | | | | | characters in all cases. Formerly we mostly just threw warnings for invalid input, and failed to detect it at all if no encoding conversion was required. The tighter check is needed to defend against SQL-injection attacks as per CVE-2006-2313 (further details will be published after release). Embedded zero (null) bytes will be rejected as well. The checks are applied during input to the backend (receipt from client or COPY IN), so it no longer seems necessary to check in textin() and related routines; any string arriving at those functions will already have been validated. Conversion failure reporting (for characters with no equivalent in the destination encoding) has been cleaned up and made consistent while at it. Also, fix a few longstanding errors in little-used encoding conversion routines: win1251_to_iso, win866_to_iso, euc_tw_to_big5, euc_tw_to_mic, mic_to_euc_tw were all broken to varying extents. Patches by Tatsuo Ishii and Tom Lane. Thanks to Akio Ishida and Yasuo Ohgaki for identifying the security issues.
* Change \' to '', for SQL standards compliance. Backpatch to 7.3, 7.4,Bruce Momjian2006-05-21
| | | | and 8.0. Later releases already patched.
* Fix nasty bug in nodeIndexscan.c's detection of duplicate tuples duringTom Lane2006-05-19
| | | | | | | | | | | | | | a multiple (OR'ed) indexscan. It was checking for duplicate tuple->t_data->t_ctid, when what it should be checking is tuple->t_self. The trouble situation occurs when a live tuple has t_ctid not pointing to itself, which can happen if an attempted UPDATE was rolled back. After a VACUUM, an unrelated tuple could be installed where the failed update tuple was, leading to one live tuple's t_ctid pointing to an unrelated tuple. If one of these tuples is fetched by an earlier OR'ed indexscan and the other by a later indexscan, nodeIndexscan.c would incorrectly ignore the second tuple. The bug exists in all 7.4.* and 8.0.* versions, but not in earlier or later branches because this code was only used in those releases. Per trouble report from Rafael Martinez Guerrero.
* Fix the sense of the test on DH_check()'s return value. This was preventingTom Lane2006-05-12
| | | | | custom-generated DH parameters from actually being used by the server. Found by Michael Fuhr.
* Remove unnecessary .seg/.section directives, per Alan Stange.Tom Lane2006-05-11
|
* Fixed memory leak bugs found by Martijn Oosterhout.Michael Meskes2006-04-24
|
* Fix ancient memory leak in PQprintTuples(); our code no longer uses thisTom Lane2006-04-19
| | | | | routine, but perhaps some applications do. Found by Martijn van Oosterhout using Coverity.
* Fix similar_escape() so that SIMILAR TO works properly for patterns involvingTom Lane2006-04-13
| | | | | | | | | | | | | | alternatives ("|" symbol). The original coding allowed the added ^ and $ constraints to be absorbed into the first and last alternatives, producing a pattern that would match more than it should. Per report from Eric Noriega. I also changed the pattern to add an ARE director ("***:"), ensuring that SIMILAR TO patterns do not change behavior if regex_flavor is changed. This is necessary to make the non-capturing parentheses work, and seems like a good idea on general principles. Back-patched as far as 7.4. 7.3 also has the bug, but a fix seems impractical because that version's regex engine doesn't have non-capturing parens.
* Repair longstanding error in btree xlog replay: XLogReadBuffer should beTom Lane2006-03-28
| | | | | | | | | | passed extend = true whenever we are reading a page we intend to reinitialize completely, even if we think the page "should exist". This is because it might indeed not exist, if the relation got truncated sometime after the current xlog record was made and before the crash we're trying to recover from. These two thinkos appear to explain both of the old bug reports discussed here: http://archives.postgresql.org/pgsql-hackers/2005-05/msg01369.php
* Fixed bug 2330: Wrong error code in case of a duplicate keyMichael Meskes2006-03-19
|
* The call to DNSServiceRegistrationCreate in postmaster.c does incorrectNeil Conway2006-03-18
| | | | | | | | | byte-swapping on the port number which causes the call to fail on Intel Macs. This patch uses htons() instead of htonl() and fixes this bug. Ashley Clark
* Tighten up SJIS byte sequence check. Now we reject invalid SJIS byteTatsuo Ishii2006-03-04
| | | | sequence such as "0x95 0x27". Patches from Akio Ishida.
* Fix three Python reference leaks in PLy_traceback(). This would resultNeil Conway2006-02-20
| | | | | | | | | | in leaking memory when invoking a PL/Python procedure that raises an exception. Unfortunately this still leaks memory, but at least the largest leak has been plugged. This patch also fixes a reference counting mistake in PLy_modify_tuple() for 8.0, 8.1 and HEAD: we don't actually own a reference to `platt', so we shouldn't Py_DECREF() it.
* Fix bug in SET SESSION AUTHORIZATION that allows unprivileged users to crashTom Lane2006-02-12
| | | | | the server, if it has been compiled with Asserts enabled (CVE-2006-0553). Thanks to Akio Ishida for reporting this problem.
* Stamp releases for 2006-02-14 releaseBruce Momjian2006-02-12
|
* Repair longstanding bug in slru/clog logic: it is possible for two backendsTom Lane2006-01-21
| | | | | | | | | | to try to create a log segment file concurrently, but the code erroneously specified O_EXCL to open(), resulting in a needless failure. Before 7.4, it was even a PANIC condition :-(. Correct code is actually simpler than what we had, because we can just say O_CREAT to start with and not need a second open() call. I believe this accounts for several recent reports of hard-to-reproduce "could not create file ...: File exists" errors in both pg_clog and pg_subtrans.
* We neglected to apply domain constraints on UNKNOWN parameters toNeil Conway2006-01-12
| | | | prepared statements, per report from David Wheeler.
* Repair "Halloween problem" in EvalPlanQual: a tuple that's been inserted byTom Lane2006-01-12
| | | | | | | | our own command (or more generally, xmin = our xact and cmin >= current command ID) should not be seen as good. Else we may try to update rows we already updated. This error was inserted last August while fixing the even bigger problem that the old coding wouldn't see *any* tuples inserted by our own transaction as good. Per report from Euler Taveira de Oliveira.
* Fix pg_dump to add the required OPERATOR() decoration to schema-qualifiedTom Lane2006-01-09
| | | | | | operator names. This is needed when dumping operator definitions that have COMMUTATOR (or similar) links to operators in other schemas. Apparently Daniel Whitter is the first person ever to try this :-(
* Fix failure to apply domain constraints to a NULL constant that's added toTom Lane2006-01-06
| | | | an INSERT target list during rule rewriting. Per report from John Supplee.
* Stamp release 7.4.11.Bruce Momjian2006-01-05
|
* Arrange to set the LC_XXX environment variables to match our locale setup.Tom Lane2006-01-05
| | | | Back-patch of previous fix in HEAD for plperl-vs-locale issue.
* Add port support for unsetenv() in back branches. Needed for localeTom Lane2006-01-05
| | | | environment fix.
* Remove DOS line endings ("\r\n") from several .po files. DOS line endingsNeil Conway2006-01-01
| | | | | are inconsistent with the rest of the .po files, and apparently cause problems for Sun's cc. Per report on IRC from "bitvector2".
* Fix long standing Asian multibyte charsets bug.Tatsuo Ishii2005-12-24
| | | | | | | | | | | See: Subject: [HACKERS] bugs with certain Asian multibyte charsets From: Tatsuo Ishii <ishii@sraoss.co.jp> To: pgsql-hackers@postgresql.org Date: Sat, 24 Dec 2005 18:25:33 +0900 (JST) for more details.
generated by cgit v1.2.3 (git 2.25.1) at 2025-07-31 03:21:51 +0000