Skip to main content

Browse the archive

https://github.com/postgres/postgres
07 April 2024, 13:56:23 UTC
sort by:
Revision Author Date Message Commit Date
d5bcb33 Tom Lane 14 August 2012, 22:38:49 UTC Stamp 9.2beta4. 14 August 2012, 22:38:49 UTC
333a54a Tom Lane 14 August 2012, 22:24:11 UTC Update release notes for 9.1.5, 9.0.9, 8.4.13, 8.3.20. 14 August 2012, 22:34:02 UTC
2ec7596 Tom Lane 14 August 2012, 22:28:37 UTC Prevent access to external files/URLs via contrib/xml2's xslt_process(). libxslt offers the ability to read and write both files and URLs through stylesheet commands, thus allowing unprivileged database users to both read and write data with the privileges of the database server. Disable that through proper use of libxslt's security options. Also, remove xslt_process()'s ability to fetch documents and stylesheets from external files/URLs. While this was a documented "feature", it was long regarded as a terrible idea. The fix for CVE-2012-3489 broke that capability, and rather than expend effort on trying to fix it, we're just going to summarily remove it. While the ability to write as well as read makes this security hole considerably worse than CVE-2012-3489, the problem is mitigated by the fact that xslt_process() is not available unless contrib/xml2 is installed, and the longstanding warnings about security risks from that should have discouraged prudent DBAs from installing it in security-exposed databases. Reported and fixed by Peter Eisentraut. Security: CVE-2012-3488 14 August 2012, 22:31:43 UTC
aa2bc1f Tom Lane 14 August 2012, 22:25:39 UTC Prevent access to external files/URLs via XML entity references. xml_parse() would attempt to fetch external files or URLs as needed to resolve DTD and entity references in an XML value, thus allowing unprivileged database users to attempt to fetch data with the privileges of the database server. While the external data wouldn't get returned directly to the user, portions of it could be exposed in error messages if the data didn't parse as valid XML; and in any case the mere ability to check existence of a file might be useful to an attacker. The ideal solution to this would still allow fetching of references that are listed in the host system's XML catalogs, so that documents can be validated according to installed DTDs. However, doing that with the available libxml2 APIs appears complex and error-prone, so we're not going to risk it in a security patch that necessarily hasn't gotten wide review. So this patch merely shuts off all access, causing any external fetch to silently expand to an empty string. A future patch may improve this. In HEAD and 9.2, also suppress warnings about undefined entities, which would otherwise occur as a result of not loading referenced DTDs. Previous branches don't show such warnings anyway, due to different error handling arrangements. Credit to Noah Misch for first reporting the problem, and for much work towards a solution, though this simplistic approach was not his preference. Also thanks to Daniel Veillard for consultation. Security: CVE-2012-3489 14 August 2012, 22:31:42 UTC
2152001 Peter Eisentraut 14 August 2012, 20:37:40 UTC Translation updates 14 August 2012, 20:37:40 UTC
30f8911 Bruce Momjian 14 August 2012, 16:36:34 UTC In documentation, change "recommendable" to "recommended", per consultation with word definitions. Backpatch to 9.2. 14 August 2012, 16:36:46 UTC
dabbd3e Tom Lane 14 August 2012, 14:54:30 UTC Update time zone data files to tzdata release 2012e. DST law changes in Morocco; Tokelau has relocated to the other side of the International Date Line; and apparently Olson had Tokelau's GMT offset wrong by an hour even before that. There are also a large number of non-significant changes in this update. Upstream took the opportunity to remove trailing whitespace, and the SCCS-style version numbers on the individual files are gone too. 14 August 2012, 14:54:30 UTC
ce36ecd Tom Lane 11 August 2012, 17:51:22 UTC Add link from COPY ref page to psql \copy. Jeff Janes 11 August 2012, 17:51:40 UTC
ca07d7e Tom Lane 11 August 2012, 16:51:30 UTC Fix dependencies generated during ALTER TABLE ADD CONSTRAINT USING INDEX. This command generated new pg_depend entries linking the index to the constraint and the constraint to the table, which match the entries made when a unique or primary key constraint is built de novo. However, it did not bother to get rid of the entries linking the index directly to the table. We had considered the issue when the ADD CONSTRAINT USING INDEX patch was written, and concluded that we didn't need to get rid of the extra entries. But this is wrong: ALTER COLUMN TYPE wasn't expecting such redundant dependencies to exist, as reported by Hubert Depesz Lubaczewski. On reflection it seems rather likely to break other things as well, since there are many bits of code that crawl pg_depend for one purpose or another, and most of them are pretty naive about what relationships they're expecting to find. Fortunately it's not that hard to get rid of the extra dependency entries, so let's do that. Back-patch to 9.1, where ALTER TABLE ADD CONSTRAINT USING INDEX was added. 11 August 2012, 16:51:30 UTC
e2af653 Bruce Momjian 10 August 2012, 21:14:47 UTC Prevent pg_upgrade from crashing if it can't write to the current directory. Backpatch to 9.2. 10 August 2012, 21:14:47 UTC
63e719e Magnus Hagander 10 August 2012, 12:49:03 UTC Fix upper limit of superuser_reserved_connections, add limit for wal_senders Should be limited to the maximum number of connections excluding autovacuum workers, not including. Add similar check for max_wal_senders, which should never be higher than max_connections. 10 August 2012, 12:51:57 UTC
86ece4b Simon Riggs 09 August 2012, 16:06:47 UTC Turn off WalSender keepalives by default, users can enable if desired 09 August 2012, 16:06:47 UTC
6a2cbe1 Simon Riggs 09 August 2012, 16:03:10 UTC Ensure all replication message info is available and correct via WalRcv 09 August 2012, 16:03:10 UTC
6f4b8a4 Simon Riggs 08 August 2012, 22:58:49 UTC Force archive_status of .done for xlogs created by dearchival/replication. This prevents spurious attempts to archive xlog files after promotion of standby, a bug introduced by cascading replication patch in 9.2. Fujii Masao, simplified and extended to cover streaming by Simon Riggs 08 August 2012, 22:58:49 UTC
7c055d6 Alvaro Herrera 08 August 2012, 21:34:20 UTC Fix typo in comment 08 August 2012, 21:40:50 UTC
cc23119 Simon Riggs 08 August 2012, 21:36:55 UTC Doc correction to point out that 9.2+ can overwrite pg_xlog files. Noted by Noah Misch, patch by Fujii Masao 08 August 2012, 21:36:55 UTC
df09dbb Simon Riggs 08 August 2012, 20:28:41 UTC Fix minor bug in XLogFileRead() that accidentally worked. Cascading replication copied the incoming file into pg_xlog but didn't set path correctly, so the first attempt to open file failed causing it to loop around and look for file in pg_xlog. So the earlier coding worked, but accidentally rather than by design. Spotted by Fujii Masao, fix by Fujii Masao and Simon Riggs 08 August 2012, 20:28:41 UTC
4bf70f2 Tom Lane 08 August 2012, 16:02:11 UTC Update isolation tests' README file. The directions explaining about running the prepared-transactions test were not updated in commit ae55d9fbe3871a5e6309d9b91629f1b0ff2b8cba. 08 August 2012, 16:02:11 UTC
5cf2307 Tom Lane 08 August 2012, 15:52:06 UTC Fix TwoPhaseGetDummyBackendId(). This was broken in commit ed0b409d22346b1b027a4c2099ca66984d94b6dd, which revised the GlobalTransactionData struct to not include the associated PGPROC as its first member, but overlooked one place where a cast was used in reliance on that equivalence. The most effective way of fixing this seems to be to create a new function that looks up the GlobalTransactionData struct given the XID, and make both TwoPhaseGetDummyBackendId and TwoPhaseGetDummyProc rely on that. Per report from Robert Ross. 08 August 2012, 15:52:06 UTC
7d947ec Bruce Momjian 07 August 2012, 17:10:44 UTC Fix pg_upgrade file share violation on Windows created by the commit 4741e9afb93f0d769655b2d18c2b73b86f281010. This was done by adding an optional second log file parameter to exec_prog(), and closing and reopening the log file between system() calls. Backpatch to 9.2. 07 August 2012, 17:10:44 UTC
4d06811 Alvaro Herrera 07 August 2012, 15:02:53 UTC Fix redundant wording 07 August 2012, 15:44:05 UTC
393b070 Simon Riggs 07 August 2012, 15:20:32 UTC fsync backup_label after pg_start_backup() Dave Kerr 07 August 2012, 15:20:32 UTC
73a7a64 Robert Haas 06 August 2012, 20:12:17 UTC Typo fixes for previous commit. Noted by Thom Brown. 06 August 2012, 20:12:35 UTC
e022ed9 Robert Haas 06 August 2012, 19:18:00 UTC Warn more vigorously about the non-transactional behavior of sequences. Craig Ringer, edited fairly heavily by me 06 August 2012, 19:19:26 UTC
da003a5 Alvaro Herrera 06 August 2012, 16:45:08 UTC Make strings identical 06 August 2012, 16:47:39 UTC
0b4660b Magnus Hagander 06 August 2012, 11:53:46 UTC Complain with proper error message if streaming stops prematurely In particular, with a controlled shutdown of the master, pg_basebackup with streaming log could terminate without an error message, even though the backup is not consistent. In passing, fix a few cases where walfile wasn't properly set to -1 after closing. Fujii Masao 06 August 2012, 11:55:52 UTC
d9c77e2 Heikki Linnakangas 06 August 2012, 10:02:15 UTC Perform conversion from Python unicode to string/bytes object via UTF-8. We used to convert the unicode object directly to a string in the server encoding by calling Python's PyUnicode_AsEncodedString function. In other words, we used Python's routines to do the encoding. However, that has a few problems. First of all, it required keeping a mapping table of Python encoding names and PostgreSQL encodings. But the real killer was that Python doesn't support EUC_TW and MULE_INTERNAL encodings at all. Instead, convert the Python unicode object to UTF-8, and use PostgreSQL's encoding conversion functions to convert from UTF-8 to server encoding. We were already doing the same in the other direction in PLyUnicode_FromString, so this is more consistent, too. Note: This makes SQL_ASCII to behave more leniently. We used to map SQL_ASCII to Python's 'ascii', which on Python means strict 7-bit ASCII only, so you got an error if the python string contained anything but pure ASCII. You no longer get an error; you get the UTF-8 representation of the string instead. Backpatch to 9.0, where these conversions were introduced. Jan Urbański 06 August 2012, 11:14:44 UTC
a411f7e Bruce Momjian 04 August 2012, 14:35:37 UTC Reword documentation for concurrent index rebuilds to be clearer. Backpatch to 9.1 and 9.2. 04 August 2012, 14:35:46 UTC
225fe68 Tom Lane 03 August 2012, 21:39:45 UTC Fix bugs with parsing signed hh:mm and hh:mm:ss fields in interval input. DecodeInterval() failed to honor the "range" parameter (the special SQL syntax for indicating which fields appear in the literal string) if the time was signed. This seems inappropriate, so make it work like the not-signed case. The inconsistency was introduced in my commit f867339c0148381eb1d01f93ab5c79f9d10211de, which as noted in its log message was only really focused on making SQL-compliant literals work per spec. Including a sign here is not per spec, but if we're going to allow it then it's reasonable to expect it to work like the not-signed case. Also, remove bogus setting of tmask, which caused subsequent processing to think that what had been given was a timezone and not an hh:mm(:ss) field, thus confusing checks for redundant fields. This seems to be an aboriginal mistake in Lockhart's commit 2cf1642461536d0d8f3a1cf124ead0eac04eb760. Add regression test cases to illustrate the changed behaviors. Back-patch as far as 8.4, where support for spec-compliant interval literals was added. Range problem reported and diagnosed by Amit Kapila, tmask problem by me. 03 August 2012, 21:40:58 UTC
bf92fb6 Bruce Momjian 03 August 2012, 20:33:09 UTC Add link to synchronous_commit variables in high availability docs. Backpatch to 9.2 Erik Rijkers 03 August 2012, 20:33:18 UTC
11de73b Tom Lane 03 August 2012, 19:41:23 UTC Improve underdocumented btree_xlog_delete_get_latestRemovedXid() code. As noted by Noah Misch, btree_xlog_delete_get_latestRemovedXid is critically dependent on the assumption that it's examining a consistent state of the database. This was undocumented though, so the seemingly-unrelated check for no active HS sessions might be thought to be merely an optional optimization. Improve comments, and add an explicit check of reachedConsistency just to be sure. This function returns InvalidTransactionId (thereby killing all HS transactions) in several cases that are not nearly unlikely enough for my taste. This commit doesn't attempt to fix those deficiencies, just document them. Back-patch to 9.2, not from any real functional need but just to keep the branches more closely synced to simplify possible future back-patching. 03 August 2012, 19:41:23 UTC
dd6947a Tom Lane 03 August 2012, 19:22:47 UTC In SPGiST replay, do conflict resolution before modifying the page. In yesterday's commit 962e0cc71e839c58fb9125fa85511b8bbb8bdbee, I added the ResolveRecoveryConflictWithSnapshot call in the wrong place. I correctly put it before spgRedoVacuumRedirect itself would modify the index page --- but not before RestoreBkpBlocks, so replay of a record with a full-page image would modify the page before kicking off any conflicting HS transactions. Oops. 03 August 2012, 19:23:30 UTC
e7d9f26 Bruce Momjian 03 August 2012, 19:15:27 UTC Document that trying to exceed temp_file_limit causes a query cancel. Backpatch to 9.2. 03 August 2012, 19:15:27 UTC
91668fc Bruce Momjian 03 August 2012, 18:02:22 UTC Document that, for psql -c, only the result of the last command is returned, per report from Aleksey Tsalolikhin Backpatch to 9.2 and 9.1. 03 August 2012, 18:02:22 UTC
51ec1d3 Bruce Momjian 03 August 2012, 16:43:37 UTC In pg_upgrade, use pg_log() instead of prep_status() for newline-terminated messages, per suggestion from Tom. Backpatch to 9.2. 03 August 2012, 16:43:37 UTC
f30b05b Tom Lane 02 August 2012, 22:23:20 UTC Stamp 9.2beta3. 02 August 2012, 22:23:20 UTC
095bcf9 Peter Eisentraut 02 August 2012, 20:01:01 UTC Translation updates 02 August 2012, 20:01:01 UTC
7f7c93f Tom Lane 02 August 2012, 19:34:21 UTC Fix race conditions associated with SPGiST redirection tuples. The correct test for whether a redirection tuple is removable is whether tuple's xid < RecentGlobalXmin, not OldestXmin; the previous coding failed to protect index searches being done in concurrent transactions that have no XID. This mirrors the recent fix in btree's page recycling logic made in commit d3abbbebe52eb1e59e621c880ad57df9d40d13f2. Also, WAL-log the newest XID of any removed redirection tuple on an index page, and apply ResolveRecoveryConflictWithSnapshot during InHotStandby WAL replay. This protects against concurrent Hot Standby transactions possibly needing to see the redirection tuple(s). Per my query of 2012-03-12 and subsequent discussion. 02 August 2012, 19:34:21 UTC
87a2379 Tom Lane 02 August 2012, 17:21:24 UTC Update release notes for libpq feature change. 02 August 2012, 17:21:24 UTC
ea56ed9 Tom Lane 02 August 2012, 17:10:36 UTC Replace libpq's "row processor" API with a "single row" mode. After taking awhile to digest the row-processor feature that was added to libpq in commit 92785dac2ee7026948962cd61c4cd84a2d052772, we've concluded it is over-complicated and too hard to use. Leave the core infrastructure changes in place (that is, there's still a row processor function inside libpq), but remove the exposed API pieces, and instead provide a "single row" mode switch that causes PQgetResult to return one row at a time in separate PGresult objects. This approach incurs more overhead than proper use of a row processor callback would, since construction of a PGresult per row adds extra cycles. However, it is far easier to use and harder to break. The single-row mode still affords applications the primary benefit that the row processor API was meant to provide, namely not having to accumulate large result sets in memory before processing them. Preliminary testing suggests that we can probably buy back most of the extra cycles by micro-optimizing construction of the extra results, but that task will be left for another day. Marko Kreen 02 August 2012, 17:10:36 UTC
f6fb9f1 Tom Lane 01 August 2012, 04:41:45 UTC Add documentation cross-reference for JSON functions. Thom Brown 01 August 2012, 04:41:45 UTC
3786b9b Tom Lane 31 July 2012, 21:56:27 UTC Fix WITH attached to a nested set operation (UNION/INTERSECT/EXCEPT). Parse analysis neglected to cover the case of a WITH clause attached to an intermediate-level set operation; it only handled WITH at the top level or WITH attached to a leaf-level SELECT. Per report from Adam Mackler. In HEAD, I rearranged the order of SelectStmt's fields to put withClause with the other fields that can appear on non-leaf SelectStmts. In back branches, leave it alone to avoid a possible ABI break for third-party code. Back-patch to 8.4 where WITH support was added. 31 July 2012, 21:56:27 UTC
63aba79 Tom Lane 31 July 2012, 18:36:58 UTC Fix syslogger so that log_truncate_on_rotation works in the first rotation. In the original coding of the log rotation stuff, we did not bother to make the truncation logic work for the very first rotation after postmaster start (or after a syslogger crash and restart). It just always appended in that case. It did not seem terribly important at the time, but we've recently had two separate complaints from people who expected it to work unsurprisingly. (Both users tend to restart the postmaster about as often as a log rotation is configured to happen, which is maybe not typical use, but still...) Since the initial log file is opened in the postmaster, fixing this requires passing down some more state to the syslogger child process. It's always been like this, so back-patch to all supported branches. 31 July 2012, 18:36:58 UTC
65f3335 Alvaro Herrera 31 July 2012, 14:09:16 UTC pg_basebackup: stylistic adjustments The most user-visible part of this is to change the long options --statusint and --noloop to --status-interval and --no-loop, respectively, per discussion. Also, consistently enclose file names in double quotes, per our conventions; and consistently use the term "transaction log file" to talk about WAL segments. (Someday we may need to go over this terminology and make it consistent across the whole source code.) Finally, reflow the code to better fit in 80 columns, and have pgindent fix it up some more. 31 July 2012, 15:02:21 UTC
776bdc4 Alvaro Herrera 31 July 2012, 13:00:23 UTC Fix memory and file descriptor leaks in pg_receivexlog/pg_basebackup When the internal loop mode was added, freeing memory and closing filedescriptors before returning became important, and a few cases in the code missed that. This is a backpatch of commit 058a050e to the 9.2 branch, which seems to have been neglected (in error, because the bugs it fixes were introduced in commit 16282ae6 which is present in both master and 9.2). Fujii Masao 31 July 2012, 15:02:21 UTC
99dd2a3 Bruce Momjian 30 July 2012, 14:15:57 UTC Now that the diskchecker.pl author has updated the download link on his website, revert the separate link to the download git repository. Backpatch from 9.0 to current. 30 July 2012, 14:15:57 UTC
62d6904 Tom Lane 27 July 2012, 23:31:19 UTC Improve reporting of error situations in find_other_exec(). This function suppressed any stderr output from the called program, which is unnecessary in the normal case and unhelpful in error cases. It also gave a rather opaque message along the lines of "fgets failure: Success" in case the called program failed to return anything on stdout. Since we've seen multiple reports of people not understanding what's wrong when pg_ctl reports this, improve the message. Back-patch to all active branches. 27 July 2012, 23:31:19 UTC
9ebe82b Bruce Momjian 27 July 2012, 01:25:26 UTC Update doc mention of diskchecker.pl to add URL for script; retain URL for description. Patch to 9.0 and later, where script is mentioned. 27 July 2012, 01:25:26 UTC
54e3c4a Bruce Momjian 26 July 2012, 18:30:07 UTC Document that the pg_upgrade user of rsync might want to skip some files, like postmaster.pid. Backpatch to 9.2. 26 July 2012, 18:32:24 UTC
07399f4 Tom Lane 26 July 2012, 18:29:32 UTC Only allow autovacuum to be auto-canceled by a directly blocked process. In the original coding of the autovacuum cancel feature, commit acac68b2bcae818bc8803b8cb8cbb17eee8d5e2b, an autovacuum process was considered a target for cancellation if it was found to hard-block any process examined in the deadlock search. This patch tightens the test so that the autovacuum must directly hard-block the current process. This should make the behavior more predictable in general, and in particular it ensures that an autovacuum will not be canceled with less than deadlock_timeout grace period. In the old coding, it was possible for an autovacuum to be canceled almost instantly, given unfortunate timing of two or more other processes' lock attempts. This also justifies the logging methodology in the recent commit d7318d43d891bd63e82dcfc27948113ed7b1db80; without this restriction, that patch isn't providing enough information to see the connection of the canceling process to the autovacuum. Like that one, patch all the way back. 26 July 2012, 18:29:32 UTC
a5bca24 Robert Haas 26 July 2012, 13:18:32 UTC Log a better message when canceling autovacuum. The old message was at DEBUG2, so typically it didn't show up in the log at all. As a result, in most cases where autovacuum was canceled, the only information that was logged was the table being vacuumed, with no indication as to what problem caused the cancel. Crank up the level to LOG and add some more details to assist with debugging. Back-patch all the way, per discussion on pgsql-hackers. 26 July 2012, 13:18:47 UTC
ba98239 Bruce Momjian 26 July 2012, 10:22:06 UTC Simplify pg_upgrade's handling when returning directory listings. Backpatch to 9.2. 26 July 2012, 10:22:20 UTC
a4a7eb3 Tom Lane 25 July 2012, 21:40:43 UTC Fix longstanding crash-safety bug with newly-created-or-reset sequences. If a crash occurred immediately after the first nextval() call for a serial column, WAL replay would restore the sequence to a state in which it appeared that no nextval() had been done, thus allowing the first sequence value to be returned again by the next nextval() call; as reported in bug #6748 from Xiangming Mei. More generally, the problem would occur if an ALTER SEQUENCE was executed on a freshly created or reset sequence. (The manifestation with serial columns was introduced in 8.2 when we added an ALTER SEQUENCE OWNED BY step to serial column creation.) The cause is that sequence creation attempted to save one WAL entry by writing out a WAL record that made it appear that the first nextval() had already happened (viz, with is_called = true), while marking the sequence's in-database state with log_cnt = 1 to show that the first nextval() need not emit a WAL record. However, ALTER SEQUENCE would emit a new WAL entry reflecting the actual in-database state (with is_called = false). Then, nextval would allocate the first sequence value and set is_called = true, but it would trust the log_cnt value and not emit any WAL record. A crash at this point would thus restore the sequence to its post-ALTER state, causing the next nextval() call to return the first sequence value again. To fix, get rid of the idea of logging an is_called status different from reality. This means that the first nextval-driven WAL record will happen at the first nextval call not the second, but the marginal cost of that is pretty negligible. In addition, make sure that ALTER SEQUENCE resets log_cnt to zero in any case where it touches sequence parameters that affect future nextval results. This will result in some user-visible changes in the contents of a sequence's log_cnt column, as reflected in the patch's regression test changes; but no application should be depending on that anyway, since it was already true that log_cnt changes rather unpredictably depending on checkpoint timing. In addition, make some basically-cosmetic improvements to get rid of sequence.c's undesirable intimacy with page layout details. It was always really trying to WAL-log the contents of the sequence tuple, so we should have it do that directly using a HeapTuple's t_data and t_len, rather than backing into it with some magic assumptions about where the tuple would be on the sequence's page. Back-patch to all supported branches. 25 July 2012, 21:42:42 UTC
7332aa6 Peter Eisentraut 25 July 2012, 19:00:00 UTC Document that pg_basebackup will create its output directory 25 July 2012, 19:01:04 UTC
408e82c Alvaro Herrera 25 July 2012, 04:02:49 UTC Add translator comments to module names 25 July 2012, 04:03:39 UTC
6804325 Alvaro Herrera 24 July 2012, 19:49:54 UTC Change syntax of new CHECK NO INHERIT constraints The initially implemented syntax, "CHECK NO INHERIT (expr)" was not deemed very good, so switch to "CHECK (expr) NO INHERIT" instead. This way it looks similar to SQL-standards compliant constraint attribute. Backport to 9.2 where the new syntax and feature was introduced. Per discussion. 24 July 2012, 20:02:18 UTC
d86fb72 Tom Lane 22 July 2012, 04:01:26 UTC Fix name collision between concurrent regression tests. Commit f5bcd398addcbeb785f0513cf28cba5d1ecd2c8a introduced a test using a table named "circles" in inherit.sql. Unfortunately, the concurrently executed constraints test was already using that table name, so the parallel regression tests would sometimes fail. Rename table to dodge the problem. Per buildfarm. 22 July 2012, 04:01:26 UTC
641054a Tom Lane 21 July 2012, 21:45:15 UTC Account for SRFs in targetlists in planner rowcount estimates. We made use of the ROWS estimate for set-returning functions used in FROM, but not for those used in SELECT targetlists; which is a bit of an oversight considering there are common usages that require the latter approach. Improve that. (I had initially thought it might be worth folding this into cost_qual_eval, but after investigation concluded that that wouldn't be very helpful, so just do it separately.) Per complaint from David Johnston. Back-patch to 9.2, but not further, for fear of destabilizing plan choices in existing releases. 21 July 2012, 21:45:15 UTC
c6c6f21 Andrew Dunstan 20 July 2012, 20:28:24 UTC Remove now unneeded results file for disabled prepared transactions case. 20 July 2012, 20:28:24 UTC
a8f0f98 Andrew Dunstan 20 July 2012, 20:02:51 UTC Remove prepared transactions from main isolation test schedule. There is no point in running this test when prepared transactions are disabled, which is the default. New make targets that include the test are provided. This will save some useless waste of cycles on buildfarm machines. Backpatch to 9.1 where these tests were introduced. 20 July 2012, 20:02:51 UTC
1247ebf Peter Eisentraut 20 July 2012, 19:34:11 UTC pg_dump: Simplify mkdir() error checking mkdir() can check for errors itself. We don't need to code that ourselves again. 20 July 2012, 19:35:02 UTC
d721f20 Alvaro Herrera 20 July 2012, 16:33:34 UTC connoinherit may be true only for CHECK constraints The code was setting it true for other constraints, which is bogus. Doing so caused bogus catalog entries for such constraints, and in particular caused an error to be raised when trying to drop a constraint of types other than CHECK from a table that has children, such as reported in bug #6712. In 9.2, additionally ignore connoinherit=true for other constraint types, to avoid having to force initdb; existing databases might already contain bogus catalog entries. Includes a catversion bump (in HEAD only). Bug report from Miroslav Šulc Analysis from Amit Kapila and Noah Misch; Amit also contributed the patch. 20 July 2012, 18:07:09 UTC
d7991a1 Tom Lane 20 July 2012, 17:09:10 UTC Fix whole-row Var evaluation to cope with resjunk columns (again). When a whole-row Var is reading the result of a subquery, we need it to ignore any "resjunk" columns that the subquery might have evaluated for GROUP BY or ORDER BY purposes. We've hacked this area before, in commit 68e40998d058c1f6662800a648ff1e1ce5d99cba, but that fix only covered whole-row Vars of named composite types, not those of RECORD type; and it was mighty klugy anyway, since it just assumed without checking that any extra columns in the result must be resjunk. A proper fix requires getting hold of the subquery's targetlist so we can actually see which columns are resjunk (whereupon we can use a JunkFilter to get rid of them). So bite the bullet and add some infrastructure to make that possible. Per report from Andrew Dunstan and additional testing by Merlin Moncure. Back-patch to all supported branches. In 8.3, also back-patch commit 292176a118da6979e5d368a4baf27f26896c99a5, which for some reason I had not done at the time, but it's a prerequisite for this change. 20 July 2012, 17:09:10 UTC
e3981da Tom Lane 19 July 2012, 23:28:27 UTC Rethink checkpointer's fsync-request table representation. Instead of having one hash table entry per relation/fork/segment, just have one per relation, and use bitmapsets to represent which specific segments need to be fsync'd. This eliminates the need to scan the whole hash table to implement FORGET_RELATION_FSYNC, which fixes the O(N^2) behavior recently demonstrated by Jeff Janes for cases involving lots of TRUNCATE or DROP TABLE operations during a single checkpoint cycle. Per an idea from Robert Haas. (FORGET_DATABASE_FSYNC still sucks, but since dropping a database is a pretty expensive operation anyway, we'll live with that.) In passing, improve the delayed-unlink code: remove the pass over the list in mdpreckpt, since it wasn't doing anything for us except supporting a useless Assert in mdpostckpt, and fix mdpostckpt so that it will absorb fsync requests every so often when clearing a large backlog of deletion requests. 19 July 2012, 23:28:27 UTC
2bc3051 Tom Lane 19 July 2012, 17:07:41 UTC Send only one FORGET_RELATION_FSYNC request when dropping a relation. We were sending one per fork, but a little bit of refactoring allows us to send just one request with forknum == InvalidForkNumber. This not only reduces pressure on the shared-memory request queue, but saves repeated traversals of the checkpointer's hash table. 19 July 2012, 17:07:41 UTC
79c4913 Heikki Linnakangas 18 July 2012, 19:34:06 UTC Refactor the way code is shared between some range type functions. Functions like range_eq, range_before etc. are exposed at the SQL-level, but they're also used internally by the GiST consistent support function. The code sharing was done by a hack, TrickFunctionCall2, which relied on the knowledge that all the functions used fn_extra the same way. This commit splits the functions into internal versions that take a TypeCacheEntry as argument, and thin wrappers to expose the functions at the SQL-level. The internal versions can then be called directly and in a less hacky way from the GiST consistent function. This is just cosmetic, but backpatch to 9.2 anyway, to avoid having a different version of this code in the 9.2 branch. That would make backpatching fixes in this area more difficult. Alexander Korotkov 18 July 2012, 20:15:08 UTC
1e9326d Tom Lane 18 July 2012, 19:40:35 UTC Fix statistics breakage from bgwriter/checkpointer process split. ForwardFsyncRequest() supposed that it could only be called in regular backends, which used to be true; but since the splitup of bgwriter and checkpointer, it is also called in the bgwriter. We do not want to count such calls in pg_stat_bgwriter.buffers_backend statistics, so fix things so that they aren't. (It's worth noting here that this implies an alarmingly large increase in the expected amount of cross-process fsync request traffic, which may well mean that the process splitup was not such a hot idea.) 18 July 2012, 19:40:35 UTC
d843589 Tom Lane 18 July 2012, 19:28:17 UTC Fix management of pendingOpsTable in auxiliary processes. mdinit() was misusing IsBootstrapProcessingMode() to decide whether to create an fsync pending-operations table in the current process. This led to creating a table not only in the startup and checkpointer processes as intended, but also in the bgwriter process, not to mention other auxiliary processes such as walwriter and walreceiver. Creation of the table in the bgwriter is fatal, because it absorbs fsync requests that should have gone to the checkpointer; instead they just sit in bgwriter local memory and are never acted on. So writes performed by the bgwriter were not being fsync'd which could result in data loss after an OS crash. I think there is no live bug with respect to walwriter and walreceiver because those never perform any writes of shared buffers; but the potential is there for future breakage in those processes too. To fix, make AuxiliaryProcessMain() export the current process's AuxProcType as a global variable, and then make mdinit() test directly for the types of aux process that should have a pendingOpsTable. Having done that, we might as well also get rid of the random bool flags such as am_walreceiver that some of the aux processes had grown. (Note that we could not have fixed the bug by examining those variables in mdinit(), because it's called from BaseInit() which is run by AuxiliaryProcessMain() before entering any of the process-type-specific code.) Back-patch to 9.2, where the problem was introduced by the split-up of bgwriter and checkpointer processes. The bogus pendingOpsTable exists in walwriter and walreceiver processes in earlier branches, but absent any evidence that it causes actual problems there, I'll leave the older branches alone. 18 July 2012, 19:28:17 UTC
ebd9e26 Tom Lane 18 July 2012, 05:23:16 UTC Get rid of useless global variable in pg_upgrade. Since the scandir() emulation was taken out of pg_upgrade, there's no longer any need for scandir_file_pattern to exist as a global variable. Replace it with a local in the one remaining function that was making use of it. 18 July 2012, 05:23:16 UTC
3d929dc Tom Lane 18 July 2012, 05:13:25 UTC Improve pg_upgrade's load_directory() function. Error out on out-of-memory, rather than returning -1, which the sole existing caller wasn't checking for anyway. There doesn't seem to be any use-case for making the caller check for failure here. Detect failure return from readdir(). Use a less platform-dependent method of calculating the entrysize. It's possible, but not yet confirmed, that this explains bug #6733, in which Mike Wilson reports a pg_upgrade crash that did not occur in 9.1. (Note that load_directory is effectively new code in 9.2, at least on platforms that have scandir().) Fix up comments, avoid uselessly using two counters, reduce the number of realloc calls to something sane. 18 July 2012, 05:13:25 UTC
4abcce8 Tom Lane 17 July 2012, 20:55:44 UTC Improve coding around the fsync request queue. In all branches back to 8.3, this patch fixes a questionable assumption in CompactCheckpointerRequestQueue/CompactBgwriterRequestQueue that there are no uninitialized pad bytes in the request queue structs. This would only cause trouble if (a) there were such pad bytes, which could happen in 8.4 and up if the compiler makes enum ForkNumber narrower than 32 bits, but otherwise would require not-currently-planned changes in the widths of other typedefs; and (b) the kernel has not uniformly initialized the contents of shared memory to zeroes. Still, it seems a tad risky, and we can easily remove any risk by pre-zeroing the request array for ourselves. In addition to that, we need to establish a coding rule that struct RelFileNode can't contain any padding bytes, since such structs are copied into the request array verbatim. (There are other places that are assuming this anyway, it turns out.) In 9.1 and up, the risk was a bit larger because we were also effectively assuming that struct RelFileNodeBackend contained no pad bytes, and with fields of different types in there, that would be much easier to break. However, there is no good reason to ever transmit fsync or delete requests for temp files to the bgwriter/checkpointer, so we can revert the request structs to plain RelFileNode, getting rid of the padding risk and saving some marginal number of bytes and cycles in fsync queue manipulation while we are at it. The savings might be more than marginal during deletion of a temp relation, because the old code transmitted an entirely useless but nonetheless expensive-to-process ForgetRelationFsync request to the background process, and also had the background process perform the file deletion even though that can safely be done immediately. In addition, make some cleanup of nearby comments and small improvements to the code in CompactCheckpointerRequestQueue/CompactBgwriterRequestQueue. 17 July 2012, 20:57:10 UTC
3d03c97 Peter Eisentraut 17 July 2012, 18:34:22 UTC Show step titles in the pg_upgrade man page The upstream XSLT stylesheets missed that case. found by Álvaro Herrera 17 July 2012, 18:35:30 UTC
82b7faa Alvaro Herrera 17 July 2012, 16:31:48 UTC Remove recently added PL/Perl encoding tests These only pass cleanly on UTF8 and SQL_ASCII encodings, besides the Japanese encoding in which they were originally written, which is clearly not good enough. Since the functionality they test has not ever been tested from PL/Perl, the best answer seems to be to remove the new tests completely. Per buildfarm results and ensuing discussion. 17 July 2012, 17:26:42 UTC
3727240 Tom Lane 16 July 2012, 17:25:26 UTC Avoid pre-determining index names during CREATE TABLE LIKE parsing. Formerly, when trying to copy both indexes and comments, CREATE TABLE LIKE had to pre-assign names to indexes that had comments, because it made up an explicit CommentStmt command to apply the comment and so it had to know the name for the index. This creates bad interactions with other indexes, as shown in bug #6734 from Daniele Varrazzo: the preassignment logic couldn't take any other indexes into account so it could choose a conflicting name. To fix, add a field to IndexStmt that allows it to carry a comment to be assigned to the new index. (This isn't a user-exposed feature of CREATE INDEX, only an internal option.) Now we don't need preassignment of index names in any situation. I also took the opportunity to refactor DefineIndex to accept the IndexStmt as such, rather than passing all its fields individually in a mile-long parameter list. Back-patch to 9.2, but no further, because it seems too dangerous to change IndexStmt or DefineIndex's API in released branches. The bug exists back to 9.0 where CREATE TABLE LIKE grew the ability to copy comments, but given the lack of prior complaints we'll just let it go unfixed before 9.2. 16 July 2012, 17:25:26 UTC
1116c9d Tom Lane 15 July 2012, 17:28:01 UTC Prevent corner-case core dump in rfree(). rfree() failed to cope with the case that pg_regcomp() had initialized the regex_t struct but then failed to allocate any memory for re->re_guts (ie, the first malloc call in pg_regcomp() failed). It would try to touch the guts struct anyway, and thus dump core. This is a sufficiently narrow corner case that it's not surprising it's never been seen in the field; but still a bug is a bug, so patch all active branches. Noted while investigating whether we need to call pg_regfree after a failure return from pg_regcomp. Other than this bug, it turns out we don't, so adjust comments appropriately. 15 July 2012, 17:28:01 UTC
eb972f3 Peter Eisentraut 14 July 2012, 10:06:09 UTC Add link to PEP 394 regarding python2 vs python3 naming 14 July 2012, 10:06:46 UTC
0bf8eb2 Tom Lane 12 July 2012, 18:29:58 UTC Fix walsender processes to establish a SIGALRM handler. Walsenders must have working SIGALRM handling during InitPostgres, but they set the handler to SIG_IGN so that nothing would happen if a timeout was reached. This could result in two failure modes: * If a walsender participated in a deadlock during its authentication transaction, and was the last to wait in the deadly embrace, the deadlock would not get cleared automatically. This would require somebody to be trying to take out AccessExclusiveLock on multiple system catalogs, so it's not very probable. * If a client failed to respond to a walsender's authentication challenge, the intended disconnect after AuthenticationTimeout wouldn't happen, and the walsender would wait indefinitely for the client. For the moment, fix in back branches only, since this is fixed in a different way in the timeout-infrastructure patch that's awaiting application to HEAD. If we choose not to apply that, then we'll need to do this in HEAD as well. 12 July 2012, 18:29:58 UTC
4810ebe Bruce Momjian 11 July 2012, 03:08:19 UTC Document that Log-Shipping Standby Servers cannot be upgraded by pg_upgrade. Backpatch to 9.2. 11 July 2012, 03:08:19 UTC
18c8dc3 Tom Lane 10 July 2012, 22:00:39 UTC Back-patch fix for extraction of fixed prefixes from regular expressions. Back-patch of commits 628cbb50ba80c83917b07a7609ddec12cda172d0 and c6aae3042be5249e672b731ebeb21875b5343010. This has been broken since 7.3, so back-patch to all supported branches. 10 July 2012, 22:00:39 UTC
f12960d Tom Lane 10 July 2012, 20:52:36 UTC Back-patch addition of pg_wchar-to-multibyte conversion functionality. Back-patch of commits 72dd6291f216440f6bb61a8733729a37c7e3b2d2, f6a05fd973a102f7e66c491d3f854864b8d24844, and 60e9c224a197aa37abb1aa3aefa3aad42da61f7f. This is needed to support fixing the regex prefix extraction bug in back branches. 10 July 2012, 20:52:36 UTC
7c460f0 Alvaro Herrera 09 July 2012, 21:36:29 UTC plperl: Skip setting UTF8 flag when in SQL_ASCII encoding When in SQL_ASCII encoding, strings passed around are not necessarily UTF8-safe. We had already fixed this in some places, but it looks like we missed some. I had to backpatch Peter Eisentraut's a8b92b60 to 9.1 in order for this patch to cherry-pick more cleanly. Patch from Alex Hunsaker, tweaked by Kyotaro HORIGUCHI and myself. Some desultory cleanup and comment addition by me, during patch review. Per bug report from Christoph Berg in 20120209102116.GA14429@msgid.df7cb.de 10 July 2012, 19:16:59 UTC
8fc7b07 Tom Lane 10 July 2012, 03:23:02 UTC Refactor pattern_fixed_prefix() to avoid dealing in incomplete patterns. Previously, pattern_fixed_prefix() was defined to return whatever fixed prefix it could extract from the pattern, plus the "rest" of the pattern. That definition was sensible for LIKE patterns, but not so much for regexes, where reconstituting a valid pattern minus the prefix could be quite tricky (certainly the existing code wasn't doing that correctly). Since the only thing that callers ever did with the "rest" of the pattern was to pass it to like_selectivity() or regex_selectivity(), let's cut out the middle-man and just have pattern_fixed_prefix's subroutines do this directly. Then pattern_fixed_prefix can return a simple selectivity number, and the question of how to cope with partial patterns is removed from its API specification. While at it, adjust the API spec so that callers who don't actually care about the pattern's selectivity (which is a lot of them) can pass NULL for the selectivity pointer to skip doing the work of computing a selectivity estimate. This patch is only an API refactoring that doesn't actually change any processing, other than allowing a little bit of useless work to be skipped. However, it's necessary infrastructure for my upcoming fix to regex prefix extraction, because after that change there won't be any simple way to identify the "rest" of the regex, not even to the low level of fidelity needed by regex_selectivity. We can cope with that if regex_fixed_prefix and regex_selectivity communicate directly, but not if we have to work within the old API. Hence, back-patch to all active branches. 10 July 2012, 03:23:02 UTC
eb1b488 Tom Lane 09 July 2012, 03:51:13 UTC Fix planner to pass correct collation to operator selectivity estimators. We can do this without creating an API break for estimation functions by passing the collation using the existing fmgr functionality for passing an input collation as a hidden parameter. The need for this was foreseen at the outset, but we didn't get around to making it happen in 9.1 because of the decision to sort all pg_statistic histograms according to the database's default collation. That meant that selectivity estimators generally need to use the default collation too, even if they're estimating for an operator that will do something different. The reason it's suddenly become more interesting is that regexp interpretation also uses a collation (for its LC_TYPE not LC_COLLATE property), and we no longer want to use the wrong collation when examining regexps during planning. It's not that the selectivity estimate is likely to change much from this; rather that we are thinking of caching compiled regexps during planner estimation, and we won't get the intended benefit if we cache them with a different collation than the executor will use. Back-patch to 9.1, both because the regexp change is likely to get back-patched and because we might as well get this right in all collation-supporting branches, in case any third-party code wants to rely on getting the collation. The patch turns out to be minuscule now that I've done it ... 09 July 2012, 03:51:13 UTC
3295387 Alvaro Herrera 06 July 2012, 20:23:30 UTC Update libpq test expected output Commit 2b443063 changed wording for some of the error messages, but neglected updating the regress output to match. 06 July 2012, 20:55:52 UTC
81aa2a5 Bruce Momjian 06 July 2012, 16:28:18 UTC Run updated copyright.pl on HEAD and 9.2 trees, updating the psql \copyright output to 2012. Backpatch to 9.2. 06 July 2012, 16:28:18 UTC
c99882a Bruce Momjian 06 July 2012, 16:21:43 UTC Have copyright.pl skip updating something that is just the current year, to avoid producing dups, e.g. 2012-2012 Backpatch to 9.2. 06 July 2012, 16:21:43 UTC
efd07bd Bruce Momjian 06 July 2012, 15:58:55 UTC Modify copyright.pl so all lines are processed, not just the first match, so files that contain embedded copyrights are updated, e.g. pgsql/help.c. Backpatch to 9.2. 06 July 2012, 15:58:55 UTC
59076b2 Bruce Momjian 06 July 2012, 15:43:59 UTC Fix copyright.pl to properly skip the .git directory by adding a basename() qualification. 06 July 2012, 15:43:59 UTC
0685047 Bruce Momjian 06 July 2012, 14:57:08 UTC Fix spacing in copyright.pl after being run with missing regex slash (now added). Backpatch to 9.2. 06 July 2012, 14:57:08 UTC
75d5e54 Bruce Momjian 06 July 2012, 13:39:21 UTC Update pg_upgrade comments for recent configpath fix. 06 July 2012, 13:39:21 UTC
11da73a Bruce Momjian 06 July 2012, 03:36:30 UTC Fix PGDATAOLD and PGDATANEW to properly set pgconfig location, per report from Tom. Backpatch to 9.2. 06 July 2012, 03:36:41 UTC
f882084 Tom Lane 05 July 2012, 21:15:11 UTC Don't try to trim "../" in join_path_components(). join_path_components() tried to remove leading ".." components from its tail argument, but it was not nearly bright enough to do so correctly unless the head argument was (a) absolute and (b) canonicalized. Rather than try to fix that logic, let's just get rid of it: there is no correctness reason to remove "..", and cosmetic concerns can be taken care of by a subsequent canonicalize_path() call. Per bug #6715 from Greg Davidson. Back-patch to all supported branches. It appears that pre-9.2, this function is only used with absolute paths as head arguments, which is why we'd not noticed the breakage before. However, third-party code might be expecting this function to work in more general cases, so it seems wise to back-patch. In HEAD and 9.2, also make some minor cosmetic improvements to callers. 05 July 2012, 21:16:25 UTC
7c58a5f Heikki Linnakangas 05 July 2012, 20:40:25 UTC Revert part of the previous patch that avoided using PLy_elog(). That caused the plpython_unicode regression test to fail on SQL_ASCII encoding, as evidenced by the buildfarm. The reason is that with the patch, you don't get the detail in the error message that you got before. That detail is actually very informative, so rather than just adjust the expected output, let's revert that part of the patch for now to make the buildfarm green again, and figure out some other way to avoid the recursion of PLy_elog() that doesn't lose the detail. 05 July 2012, 20:43:46 UTC
7732880 Heikki Linnakangas 05 July 2012, 18:45:24 UTC Fix mapping of PostgreSQL encodings to Python encodings. Windows encodings, "win1252" and so forth, are named differently in Python, like "cp1252". Also, if the PyUnicode_AsEncodedString() function call fails for some reason, use a plain ereport(), not a PLy_elog(), to report that error. That avoids recursion and crash, if PLy_elog() tries to call PLyUnicode_Bytes() again. This fixes bug reported by Asif Naeem. Backpatch down to 9.0, before that plpython didn't even try these conversions. Jan Urbański, with minor comment improvements by me. 05 July 2012, 19:31:47 UTC
071589c Bruce Momjian 05 July 2012, 01:58:48 UTC Fix missing regex slash that caused perltidy to get confused on copyright.pl. Backpatch to 9.2. 05 July 2012, 01:58:48 UTC
2bc09ff Bruce Momjian 05 July 2012, 01:47:48 UTC Run newly-configured perltidy script on Perl files. Run on HEAD and 9.2. 05 July 2012, 01:47:48 UTC
9c6f8be Bruce Momjian 04 July 2012, 21:36:50 UTC Have pg_dump in binary-upgrade mode properly drop user-created extensions that might exist in the new empty cluster databases, like plpgsql. Backpatch to 9.2. 04 July 2012, 21:36:50 UTC
d3341d4 Magnus Hagander 04 July 2012, 13:13:09 UTC Set the write location in the pg_receivexlog status messages This makes it possible for the master to track how much data has actually been written my pg_receivexlog - and not just how much has been sent towards it. 04 July 2012, 13:15:02 UTC
8c8adf4 Magnus Hagander 04 July 2012, 13:10:46 UTC Always treat a standby returning an an invalid flush location as async This ensures that a standby such as pg_receivexlog will not be selected as sync standby - which would cause the master to block waiting for a location that could never happen. Fujii Masao 04 July 2012, 13:14:57 UTC
5c5d548 Magnus Hagander 04 July 2012, 07:22:21 UTC Remove reference to default wal_buffers being 8 This hasn't been true since 9.1, when the default was changed to -1. Remove the reference completely, keeping the discussion of the parameter and it's shared memory effects on the config page. 04 July 2012, 07:23:31 UTC
back to top