| b7f59e6 | Peter Eisentraut | 08 October 2013, 03:17:38 UTC | Stamp 9.3.1. | 08 October 2013, 03:17:38 UTC |
| 4e80950 | Peter Eisentraut | 08 October 2013, 02:42:52 UTC | Revert "Document support for VPATH builds of extensions." This reverts commit 9598134e3030a883ff6eea8a822466ce5143ffeb. | 08 October 2013, 02:42:52 UTC |
| 9fba0cb | Peter Eisentraut | 08 October 2013, 02:32:04 UTC | Revert "Backpatch pgxs vpath build and installation fixes." This reverts commit f8110c5f66ad079e3dbc0b66bed06207c43643ef. pending resolution of http://www.postgresql.org/message-id/1381193255.25702.4.camel@vanquo.pezone.net | 08 October 2013, 02:32:04 UTC |
| 4b41460 | Peter Eisentraut | 08 October 2013, 02:31:31 UTC | Revert "Ensure installation dirs are built before contents are installed (v2)" This reverts commit 7f165f2587f6dafe7d4d438136dd959ed5610979. pending resolution of http://www.postgresql.org/message-id/1381193255.25702.4.camel@vanquo.pezone.net | 08 October 2013, 02:31:31 UTC |
| 2589a5a | Bruce Momjian | 08 October 2013, 01:35:02 UTC | docs: update release notes for 8.4.18, 9.0.14, 9.1.10, 9.2.5, 9.3.1 | 08 October 2013, 01:35:02 UTC |
| cc736ed | Heikki Linnakangas | 07 October 2013, 20:57:40 UTC | Fix bugs in SSI tuple locking. 1. In heap_hot_search_buffer(), the PredicateLockTuple() call is passed wrong offset number. heapTuple->t_self is set to the tid of the first tuple in the chain that's visited, not the one actually being read. 2. CheckForSerializableConflictIn() uses the tuple's t_ctid field instead of t_self to check for exiting predicate locks on the tuple. If the tuple was updated, but the updater rolled back, t_ctid points to the aborted dead tuple. Reported by Hannu Krosing. Backpatch to 9.1. | 07 October 2013, 21:03:24 UTC |
| 4750eae | Peter Eisentraut | 07 October 2013, 20:27:04 UTC | Translation updates | 07 October 2013, 20:27:04 UTC |
| ef388b6 | Kevin Grittner | 07 October 2013, 19:26:54 UTC | Eliminate xmin from hash tag for predicate locks on heap tuples. If a tuple was frozen while its predicate locks mattered, read-write dependencies could be missed, resulting in failure to detect conflicts which could lead to anomalies in committed serializable transactions. This field was added to the tag when we still thought that it was necessary to carry locks forward to a new version of an updated row. That was later proven to be unnecessary, which allowed simplification of the code, but elimination of xmin from the tag was missed at the time. Per report and analysis by Heikki Linnakangas. Backpatch to 9.1. | 07 October 2013, 19:26:54 UTC |
| 9598134 | Andrew Dunstan | 07 October 2013, 03:03:57 UTC | Document support for VPATH builds of extensions. Cédric Villemain and me. | 07 October 2013, 03:03:57 UTC |
| 6f85b31 | Bruce Momjian | 05 October 2013, 14:18:02 UTC | pg_upgrade doc: link mode additions Mention that link mode uses less disk space, and uses junction points on Windows. Backpatch to 9.3. | 05 October 2013, 14:18:17 UTC |
| 3078f21 | Alvaro Herrera | 04 October 2013, 17:25:30 UTC | add multixact-no-deadlock to schedule | 04 October 2013, 18:59:22 UTC |
| 0ac659d | Alvaro Herrera | 04 October 2013, 17:24:46 UTC | Make some isolationtester specs more complete Also, make sure they pass on all transaction isolation levels. | 04 October 2013, 18:59:22 UTC |
| eb8a811 | Alvaro Herrera | 04 October 2013, 13:32:48 UTC | isolationtester: Allow tuples to be returned in more places Previously, isolationtester would forbid returning tuples in session-specific teardown (but not global teardown), as well as in global setup. Allow these places to return tuples, too. | 04 October 2013, 18:59:21 UTC |
| e632b6b | Peter Eisentraut | 03 October 2013, 01:33:26 UTC | doc: Correct psycopg URL | 03 October 2013, 01:34:06 UTC |
| 5132518 | Magnus Hagander | 02 October 2013, 14:42:36 UTC | Fix copy/paste error | 02 October 2013, 14:43:46 UTC |
| ecce261 | Alvaro Herrera | 01 October 2013, 20:36:15 UTC | Remove broken PGXS code for pg_xlogdump With the PGXS boilerplate in place, pg_xlogdump currently fails with an ominous error message that certain targets cannot be built because certain files do not exist. Remove that and instead throw a quick error message alerting the user of the actual problem, which should be easier to diagnose that the statu quo. Andres Freund | 01 October 2013, 20:39:46 UTC |
| d794eae | Andrew Dunstan | 30 September 2013, 15:33:54 UTC | Add missing condition for pg_depend in hstore migration script. Error noted by Andres Freund. | 30 September 2013, 15:38:31 UTC |
| 7f165f2 | Andrew Dunstan | 30 September 2013, 14:17:30 UTC | Ensure installation dirs are built before contents are installed (v2) Push dependency on installdirs down to individual targets. Christoph Berg | 30 September 2013, 14:19:56 UTC |
| f609d07 | Heikki Linnakangas | 30 September 2013, 08:29:09 UTC | Fix snapshot leak if lo_open called on non-existent object. lo_open registers the currently active snapshot, and checks if the large object exists after that. Normally, snapshots registered by lo_open are unregistered at end of transaction when the lo descriptor is closed, but if we error out before the lo descriptor is added to the list of open descriptors, it is leaked. Fix by moving the snapshot registration to after checking if the large object exists. Reported by Pavel Stehule. Backpatch to 8.4. The snapshot registration system was introduced in 8.4, so prior versions are not affected (and not supported, anyway). | 30 September 2013, 09:53:56 UTC |
| 311be2a | Andrew Dunstan | 30 September 2013, 02:46:30 UTC | Fix makefile broken by hstore fix. | 30 September 2013, 02:46:30 UTC |
| 83e83aa | Andrew Dunstan | 29 September 2013, 21:41:56 UTC | Use a new hstore extension version for added json functions. This should have been done when the json functionality was added to hstore in 9.3.0. To handle this correctly, the upgrade script therefore uses conditional logic by using plpgsql in a DO statement to add the two new functions and the new cast. If hstore_to_json_loose is detected as already present and dependent on the hstore extension nothing is done. This will require that the database be loaded with plpgsql. People who have installed the earlier and spurious 1.1 version of hstore will need to do: ALTER EXTENSION hstore UPDATE; to pick up the new functions properly. | 29 September 2013, 21:51:11 UTC |
| f8110c5 | Andrew Dunstan | 29 September 2013, 21:28:16 UTC | Backpatch pgxs vpath build and installation fixes. This is a backpatch of commits d942f9d9, 82b01026, and 6697aa2bc, back to release 9.1 where we introduced extensions which make heavy use of the PGXS infrastructure. | 29 September 2013, 21:28:16 UTC |
| 32d8602 | Andrew Dunstan | 26 September 2013, 21:46:07 UTC | Fix erroneous statements about multiply specified JSON columns. The behaviour in json_populate_record() and json_populate_recordset() was changed during development but the docs were not. | 26 September 2013, 21:46:07 UTC |
| 5bdf02c | Heikki Linnakangas | 26 September 2013, 08:24:40 UTC | Fix spurious warning after vacuuming a page on a table with no indexes. There is a rare race condition, when a transaction that inserted a tuple aborts while vacuum is processing the page containing the inserted tuple. Vacuum prunes the page first, which normally removes any dead tuples, but if the inserting transaction aborts right after that, the loop after pruning will see a dead tuple and remove it instead. That's OK, but if the page is on a table with no indexes, and the page becomes completely empty after removing the dead tuple (or tuples) on it, it will be immediately marked as all-visible. That's OK, but the sanity check in vacuum would throw a warning because it thinks that the page contains dead tuples and was nevertheless marked as all-visible, even though it just vacuumed away the dead tuples and so it doesn't actually contain any. Spotted this while reading the code. It's difficult to hit the race condition otherwise, but can be done by putting a breakpoint after the heap_page_prune() call. Backpatch all the way to 8.4, where this code first appeared. | 26 September 2013, 08:38:15 UTC |
| 3393675 | Heikki Linnakangas | 25 September 2013, 13:02:00 UTC | Plug memory leak in range_cmp function. B-tree operators are not allowed to leak memory into the current memory context. Range_cmp leaked detoasted copies of the arguments. That caused a quick out-of-memory error when creating an index on a range column. Reported by Marian Krucina, bug #8468. | 25 September 2013, 13:05:24 UTC |
| ea9a2bc | Alvaro Herrera | 24 September 2013, 21:19:14 UTC | Fix pgindent comment breakage | 24 September 2013, 21:21:28 UTC |
| 98a746c | Noah Misch | 23 September 2013, 20:00:13 UTC | Use @libdir@ in both of regress/{input,output}/security_label.source Though @libdir@ almost always matches @abs_builddir@ in this context, the test could only fail if they differed. Back-patch to 9.1, where the test was introduced. Hamid Quddus Akhtar | 23 September 2013, 20:00:47 UTC |
| faf2971 | Robert Haas | 23 September 2013, 18:57:01 UTC | doc: Clarify that file_fdw options require values. Mike Blackwell and Robert Haas | 23 September 2013, 19:02:08 UTC |
| 73c4e52 | Stephen Frost | 23 September 2013, 12:33:41 UTC | Fix SSL deadlock risk in libpq In libpq, we set up and pass to OpenSSL callback routines to handle locking. When we run out of SSL connections, we try to clean things up by de-registering the hooks. Unfortunately, we had a few calls into the OpenSSL library after these hooks were de-registered during SSL cleanup which lead to deadlocking. This moves the thread callback cleanup to be after all SSL-cleanup related OpenSSL library calls. I've been unable to reproduce the deadlock with this fix. In passing, also move the close_SSL call to be after unlocking our ssl_config mutex when in a failure state. While it looks pretty unlikely to be an issue, it could have resulted in deadlocks if we ended up in this code path due to something other than SSL_new failing. Thanks to Heikki for pointing this out. Back-patch to all supported versions; note that the close_SSL issue only goes back to 9.0, so that hunk isn't included in the 8.4 patch. Initially found and reported by Vesa-Matti J Kari; many thanks to both Heikki and Andres for their help running down the specific issue and reviewing the patch. | 23 September 2013, 12:42:37 UTC |
| 62ff655 | Heikki Linnakangas | 23 September 2013, 07:17:52 UTC | Fix two timeline handling bugs in pg_receivexlog. When a timeline history file is fetched from server, it is initially created with a temporary file name, and renamed to place. However, the temporary file name was constructed using an uninitialized buffer. Usually that meant that the file was created in current directory instead of the target, which usually goes unnoticed, but if the target is on a different filesystem than the current dir, the rename() would fail. Fix that. The second issue is that pg_receivexlog would not take .partial files into account when determining when scanning the target directory for existing WAL files. If the timeline has switched in the server several times in the last WAL segment, and pg_receivexlog is restarted, it would choose a too old starting point. That's not a problem as long as the old WAL segment exists in the server and can be streamed over, but will cause a failure if it's not. Backpatch to 9.3, where this timeline handling code was written. Analysed by Andrew Gierth, bug #8453, based on a bug report on IRC. | 23 September 2013, 07:40:25 UTC |
| 3451faa | Alvaro Herrera | 16 September 2013, 18:45:00 UTC | Rename various "freeze multixact" variables It seems to make more sense to use "cutoff multixact" terminology throughout the backend code; "freeze" is associated with replacing of an Xid with FrozenTransactionId, which is not what we do for MultiXactIds. Andres Freund Some adjustments by Álvaro Herrera | 16 September 2013, 18:56:11 UTC |
| 374652f | Noah Misch | 12 September 2013, 00:10:15 UTC | Ignore interrupts during quickdie(). Once the administrator has called for an immediate shutdown or a backend crash has triggered a reinitialization, no mere SIGINT or SIGTERM should change that course. Such derailment remains possible when the signal arrives before quickdie() blocks signals. That being a narrow race affecting most PostgreSQL signal handlers in some way, leave it for another patch. Back-patch this to all supported versions. | 12 September 2013, 00:14:07 UTC |
| 1eea0eb | Michael Meskes | 08 September 2013, 10:59:43 UTC | Return error if allocation of new element was not possible. Found by Coverity. | 08 September 2013, 11:13:03 UTC |
| 3560dbc | Michael Meskes | 08 September 2013, 10:49:54 UTC | Close file to no leak file descriptor memory. Found by Coverity. | 08 September 2013, 11:13:03 UTC |
| fb843b2 | Jeff Davis | 05 September 2013, 06:30:27 UTC | Improve Range Types and Exclusion Constraints example. Make the examples self-contained to avoid confusion. Per bug report 8367 from KOIZUMI Satoru. | 05 September 2013, 14:26:26 UTC |
| dacd258 | Bruce Momjian | 04 September 2013, 21:04:12 UTC | Remove dead URL mention in OSX startup script Backpatch to 9.3. Per suggestion from Gavan Schneider | 04 September 2013, 21:04:57 UTC |
| 6987608 | Tom Lane | 03 September 2013, 22:32:23 UTC | Don't fail for bad GUCs in CREATE FUNCTION with check_function_bodies off. The previous coding attempted to activate all the GUC settings specified in SET clauses, so that the function validator could operate in the GUC environment expected by the function body. However, this is problematic when restoring a dump, since the SET clauses might refer to database objects that don't exist yet. We already have the parameter check_function_bodies that's meant to prevent forward references in function definitions from breaking dumps, so let's change CREATE FUNCTION to not install the SET values if check_function_bodies is off. Authors of function validators were already advised not to make any "context sensitive" checks when check_function_bodies is off, if indeed they're checking anything at all in that mode. But extend the documentation to point out the GUC issue in particular. (Note that we still check the SET clauses to some extent; the behavior with !check_function_bodies is now approximately equivalent to what ALTER DATABASE/ROLE have been doing for awhile with context-dependent GUCs.) This problem can be demonstrated in all active branches, so back-patch all the way. | 03 September 2013, 22:32:23 UTC |
| 30b5b3b | Alvaro Herrera | 03 September 2013, 20:52:11 UTC | Update obsolete comment | 03 September 2013, 20:54:03 UTC |
| 9720164 | Greg Stark | 03 September 2013, 12:27:34 UTC | Fix thinko in worker_spi, count(*) returns a bigint. Thanks RhodiumToad | 03 September 2013, 15:44:20 UTC |
| 767de7d | Robert Haas | 03 September 2013, 15:16:37 UTC | docs: Clarify that we also support Solaris versions greater than 10. MauMau | 03 September 2013, 15:22:31 UTC |
| da645b3 | Tom Lane | 02 September 2013, 20:53:17 UTC | Stamp 9.3.0. | 02 September 2013, 20:53:17 UTC |
| e3d02a1 | Tom Lane | 02 September 2013, 19:06:21 UTC | Update time zone data files to tzdata release 2013d. DST law changes in Israel, Morocco, Palestine, Paraguay. Historical corrections for Macquarie Island. | 02 September 2013, 19:06:30 UTC |
| 4e1e5d3 | Andrew Dunstan | 02 September 2013, 18:37:53 UTC | Fix relfrozenxid query in docs to include TOAST tables. The original query ignored TOAST tables which could result in tables needing a vacuum not being reported. Backpatch to all live branches. | 02 September 2013, 18:37:53 UTC |
| c7ef895 | Peter Eisentraut | 02 September 2013, 06:28:21 UTC | Translation updates | 02 September 2013, 06:28:21 UTC |
| b9a06c9 | Tom Lane | 01 September 2013, 23:43:02 UTC | Update "Using EXPLAIN" documentation examples using current code. It seems like a good idea to update these examples since some fairly basic planner behaviors have changed in 9.3; notably that the startup cost for an indexscan plan node is no longer invariably estimated at 0.00. | 01 September 2013, 23:43:26 UTC |
| 3234a64 | Tom Lane | 01 September 2013, 03:53:33 UTC | Update 9.3 release notes. Some corrections, a lot of copy-editing. Set projected release date as 2013-09-09. | 01 September 2013, 03:53:33 UTC |
| 3c2a425 | Tom Lane | 31 August 2013, 01:40:21 UTC | Improve regression test for #8410. The previous version of the query disregarded the result of the MergeAppend instead of checking its results. Andres Freund | 31 August 2013, 01:40:49 UTC |
| ce58aad | Tom Lane | 30 August 2013, 23:27:40 UTC | Add test case for bug #8410. Per Andres Freund. | 30 August 2013, 23:27:47 UTC |
| 16e8e36 | Tom Lane | 30 August 2013, 23:15:21 UTC | Reset the binary heap in MergeAppend rescans. Failing to do so can cause queries to return wrong data, error out or crash. This requires adding a new binaryheap_reset() method to binaryheap.c, but that probably should have been there anyway. Per bug #8410 from Terje Elde. Diagnosis and patch by Andres Freund. | 30 August 2013, 23:15:32 UTC |
| dfed97b | Alvaro Herrera | 29 August 2013, 16:33:50 UTC | Make error wording more consistent | 29 August 2013, 17:11:08 UTC |
| e536d47 | Andrew Dunstan | 26 August 2013, 18:58:14 UTC | Unconditionally use the WSA equivalents of Socket error constants. This change will only apply to mingw compilers, and has been found necessary by late versions of the mingw-w64 compiler. It's the same as what is done elsewhere for the Microsoft compilers. Backpatch of commit 73838b5251e. Problem reported by Michael Cronenworth, although not his patch. | 26 August 2013, 18:58:14 UTC |
| a5f11e2 | Tom Lane | 24 August 2013, 19:14:21 UTC | Account better for planning cost when choosing whether to use custom plans. The previous coding in plancache.c essentially used 10% of the estimated runtime as its cost estimate for planning. This can be pretty bogus, especially when the estimated runtime is very small, such as in a simple expression plan created by plpgsql, or a simple INSERT ... VALUES. While we don't have a really good handle on how planning time compares to runtime, it seems reasonable to use an estimate based on the number of relations referenced in the query, with a rather large multiplier. This patch uses 1000 * cpu_operator_cost * (nrelations + 1), so that even a trivial query will be charged 1000 * cpu_operator_cost for planning. This should address the problem reported by Marc Cousin and others that 9.2 and up prefer custom plans in cases where the planning time greatly exceeds what can be saved. | 24 August 2013, 19:14:21 UTC |
| 3cf8905 | Magnus Hagander | 24 August 2013, 15:11:31 UTC | Don't crash when pg_xlog is empty and pg_basebackup -x is used The backup will not work (without a logarchive, and that's the whole point of -x) in this case, this patch just changes it to throw an error instead of crashing when this happens. Noticed and diagnosed by TAKATSUKA Haruka | 24 August 2013, 15:14:18 UTC |
| c19617d | Tom Lane | 23 August 2013, 21:30:56 UTC | In locate_grouping_columns(), don't expect an exact match of Var typmods. It's possible that inlining of SQL functions (or perhaps other changes?) has exposed typmod information not known at parse time. In such cases, Vars generated by query_planner might have valid typmod values while the original grouping columns only have typmod -1. This isn't a semantic problem since the behavior of grouping only depends on type not typmod, but it breaks locate_grouping_columns' use of tlist_member to locate the matching entry in query_planner's result tlist. We can fix this without an excessive amount of new code or complexity by relying on the fact that locate_grouping_columns only gets called when make_subplanTargetList has set need_tlist_eval == false, and that can only happen if all the grouping columns are simple Vars. Therefore we only need to search the sub_tlist for a matching Var, and we can reasonably define a "match" as being a match of the Var identity fields varno/varattno/varlevelsup. The code still Asserts that vartype matches, but ignores vartypmod. Per bug #8393 from Evan Martin. The added regression test case is basically the same as his example. This has been broken for a very long time, so back-patch to all supported branches. | 23 August 2013, 21:30:56 UTC |
| e6d3f5b | Tom Lane | 21 August 2013, 17:38:20 UTC | Fix hash table size estimation error in choose_hashed_distinct(). We should account for the per-group hashtable entry overhead when considering whether to use a hash aggregate to implement DISTINCT. The comparable logic in choose_hashed_grouping() gets this right, but I think I omitted it here in the mistaken belief that there would be no overhead if there were no aggregate functions to be evaluated. This can result in more than 2X underestimate of the hash table size, if the tuples being aggregated aren't very wide. Per report from Tomas Vondra. This bug is of long standing, but per discussion we'll only back-patch into 9.3. Changing the estimation behavior in stable branches seems to carry too much risk of destabilizing plan choices for already-tuned applications. | 21 August 2013, 17:38:38 UTC |
| c9d7c19 | Bruce Momjian | 20 August 2013, 13:39:00 UTC | release notes: update link to 9.3 PL/pgSQL constraint error info Backpatch to 9.3. Pavel Stehule | 20 August 2013, 13:39:42 UTC |
| ce52c6f | Tom Lane | 19 August 2013, 23:45:10 UTC | Stamp 9.3rc1. | 19 August 2013, 23:45:10 UTC |
| 59bc4a4 | Tom Lane | 19 August 2013, 23:36:06 UTC | Be more wary of unwanted whitespace in pgstat_reset_remove_files(). sscanf isn't the easiest thing to use for exact pattern checks ... also, don't use strncmp where strcmp will do. | 19 August 2013, 23:36:06 UTC |
| db5b49c | Alvaro Herrera | 19 August 2013, 21:48:17 UTC | Fix removal of files in pgstats directories Instead of deleting all files in stats_temp_directory and the permanent directory on a crash, only remove those files that match the pattern of files we actually write in them, to avoid possibly clobbering existing unrelated contents of the temporary directory. Per complaint from Jeff Janes, and subsequent discussion, starting at message CAMkU=1z9+7RsDODnT4=cDFBRBp8wYQbd_qsLcMtKEf-oFwuOdQ@mail.gmail.com Also, fix a bug in the same routine to avoid removing files from the permanent directory twice (instead of once from that directory and then from the temporary directory), also per report from Jeff Janes, in message CAMkU=1wbk947=-pAosDMX5VC+sQw9W4ttq6RM9rXu=MjNeEQKA@mail.gmail.com | 19 August 2013, 21:52:52 UTC |
| 38c6923 | Heikki Linnakangas | 19 August 2013, 17:57:53 UTC | Rename the "fast_promote" file to just "promote". This keeps the usual trigger file name unchanged from 9.2, avoiding nasty issues if you use a pre-9.3 pg_ctl binary with a 9.3 server or vice versa. The fallback behavior of creating a full checkpoint before starting up is now triggered by a file called "fallback_promote". That can be useful for debugging purposes, but we don't expect any users to have to resort to that and we might want to remove that in the future, which is why the fallback mechanism is undocumented. | 19 August 2013, 18:01:14 UTC |
| b19e5a6 | Tom Lane | 19 August 2013, 17:19:28 UTC | Fix qual-clause-misplacement issues with pulled-up LATERAL subqueries. In an example such as SELECT * FROM i LEFT JOIN LATERAL (SELECT * FROM j WHERE i.n = j.n) j ON true; it is safe to pull up the LATERAL subquery into its parent, but we must then treat the "i.n = j.n" clause as a qual clause of the LEFT JOIN. The previous coding in deconstruct_recurse mistakenly labeled the clause as "is_pushed_down", resulting in wrong semantics if the clause were applied at the join node, as per an example submitted awhile ago by Jeremy Evans. To fix, postpone processing of such clauses until we return back up to the appropriate recursion depth in deconstruct_recurse. In addition, tighten the is-safe-to-pull-up checks in is_simple_subquery; we previously missed the possibility that the LATERAL subquery might itself contain an outer join that makes lateral references in lower quals unsafe. A regression test case equivalent to Jeremy's example was already in my commit of yesterday, but was giving the wrong results because of this bug. This patch fixes the expected output for that, and also adds a test case for the second problem. | 19 August 2013, 17:19:51 UTC |
| b3c55ae | Alvaro Herrera | 19 August 2013, 16:33:07 UTC | Fix pg_upgrade failure from servers older than 9.3 When upgrading from servers of versions 9.2 and older, and MultiXactIds have been used in the old server beyond the first page (that is, 2048 multis or more in the default 8kB-page build), pg_upgrade would set the next multixact offset to use beyond what has been allocated in the new cluster. This would cause a failure the first time the new cluster needs to use this value, because the pg_multixact/offsets/ file wouldn't exist or wouldn't be large enough. To fix, ensure that the transient server instances launched by pg_upgrade extend the file as necessary. Per report from Jesse Denardo in CANiVXAj4c88YqipsyFQPboqMudnjcNTdB3pqe8ReXqAFQ=HXyA@mail.gmail.com | 19 August 2013, 16:56:29 UTC |
| 064eb50 | Bruce Momjian | 19 August 2013, 16:26:22 UTC | release notes: remove username from 9.3 major item Etsuro Fujita | 19 August 2013, 16:26:22 UTC |
| 3e5dd59 | Peter Eisentraut | 19 August 2013, 03:36:20 UTC | Translation updates | 19 August 2013, 03:36:20 UTC |
| 5a91ea7 | Kevin Grittner | 18 August 2013, 21:24:59 UTC | Remove relcache entry invalidation in REFRESH MATERIALIZED VIEW. This was added as part of the attempt to support unlogged matviews along with a populated status. It got missed when unlogged support was removed pre-commit. Noticed by Noah Misch. Back-patched to 9.3 branch. | 18 August 2013, 21:24:59 UTC |
| 7c8de5d | Peter Eisentraut | 18 August 2013, 01:46:32 UTC | libpq: Report strerror on pthread_mutex_lock() failure | 18 August 2013, 01:47:11 UTC |
| 8820b50 | Tom Lane | 18 August 2013, 00:36:29 UTC | Fix thinko in comment. | 18 August 2013, 00:36:39 UTC |
| 517db49 | Tom Lane | 18 August 2013, 00:22:41 UTC | Fix planner problems with LATERAL references in PlaceHolderVars. The planner largely failed to consider the possibility that a PlaceHolderVar's expression might contain a lateral reference to a Var coming from somewhere outside the PHV's syntactic scope. We had a previous report of a problem in this area, which I tried to fix in a quick-hack way in commit 4da6439bd8553059766011e2a42c6e39df08717f, but Antonin Houska pointed out that there were still some problems, and investigation turned up other issues. This patch largely reverts that commit in favor of a more thoroughly thought-through solution. The new theory is that a PHV's ph_eval_at level cannot be higher than its original syntactic level. If it contains lateral references, those don't change the ph_eval_at level, but rather they create a lateral-reference requirement for the ph_eval_at join relation. The code in joinpath.c needs to handle that. Another issue is that createplan.c wasn't handling nested PlaceHolderVars properly. In passing, push knowledge of lateral-reference checks for join clauses into join_clause_is_movable_to. This is mainly so that FDWs don't need to deal with it. This patch doesn't fix the original join-qual-placement problem reported by Jeremy Evans (and indeed, one of the new regression test cases shows the wrong answer because of that). But the PlaceHolderVar problems need to be fixed before that issue can be addressed, so committing this separately seems reasonable. | 18 August 2013, 00:22:41 UTC |
| 2505aae | Bruce Momjian | 16 August 2013, 22:01:04 UTC | release notes: update 9.3 major feature list Backpatch to 9.3. | 16 August 2013, 22:01:04 UTC |
| c359ff2 | Bruce Momjian | 16 August 2013, 20:54:18 UTC | release notes: Update to 9.3 git current Backpatch to 9.3, of course. | 16 August 2013, 20:54:40 UTC |
| 8e2eca4 | Robert Haas | 16 August 2013, 19:28:03 UTC | Rename some bgworker functions as we've done in master. Commit 2dee7998f93062e2ae7fcc9048ff170e528d1724 renames these functions in master, for consistency; per discussion, backport just the renaming portion of that commit to 9.3 to keep the branches in sync. Michael Paquier | 16 August 2013, 19:31:50 UTC |
| ae3c8c5 | Bruce Momjian | 16 August 2013, 15:09:09 UTC | pg_upgrade: shut down server after auth failure Register atexit() server shutdown if pg_ctl successfully started the server, but we can't connect to it. Backpatch to 9.3. Pavel Raiskup | 16 August 2013, 15:09:09 UTC |
| cdcddc4 | Kevin Grittner | 15 August 2013, 18:16:45 UTC | Don't allow ALTER MATERIALIZED VIEW ADD UNIQUE. Was accidentally allowed, but not documented and lacked support for rename or drop once created. Per report from Noah Misch. | 15 August 2013, 18:16:45 UTC |
| d2fa20a | Magnus Hagander | 15 August 2013, 16:24:25 UTC | Add tab completion for \dx in psql | 15 August 2013, 16:43:06 UTC |
| 3ed990b | Peter Eisentraut | 15 August 2013, 03:18:49 UTC | Treat timeline IDs as unsigned in replication parser Timeline IDs are unsigned ints everywhere, except the replication parser treated them as signed ints. | 15 August 2013, 03:20:55 UTC |
| 9e3f42f | Peter Eisentraut | 15 August 2013, 03:00:34 UTC | Improve error message when view is not updatable Avoid using the term "updatable" in confusing ways. Suggest a trigger first, before a rule. | 15 August 2013, 03:00:34 UTC |
| 6c5f68e | Tom Lane | 14 August 2013, 22:38:36 UTC | Remove ph_may_need from PlaceHolderInfo, with attendant simplifications. The planner logic that attempted to make a preliminary estimate of the ph_needed levels for PlaceHolderVars seems to be completely broken by lateral references. Fortunately, the potential join order optimization that this code supported seems to be of relatively little value in practice; so let's just get rid of it rather than trying to fix it. Getting rid of this allows fairly substantial simplifications in placeholder.c, too, so planning in such cases should be a bit faster. Issue noted while pursuing bugs reported by Jeremy Evans and Antonin Houska, though this doesn't in itself fix either of their reported cases. What this does do is prevent an Assert crash in the kind of query illustrated by the added regression test. (I'm not sure that the plan for that query is stable enough across platforms to be usable as a regression test output ... but we'll soon find out from the buildfarm.) Back-patch to 9.3. The problem case can't arise without LATERAL, so no need to touch older branches. | 14 August 2013, 22:38:36 UTC |
| 8505237 | Kevin Grittner | 14 August 2013, 17:43:01 UTC | Remove Assert that matview is not in system schema from REFRESH. We don't want to prevent an extension which creates a matview from being installed in pg_catalog. Issue was raised by Hitoshi Harada. Backpatched to 9.3. | 14 August 2013, 17:43:01 UTC |
| 6d8186f | Tom Lane | 13 August 2013, 19:24:56 UTC | Emit a log message if output is about to be redirected away from stderr. We've seen multiple cases of people looking at the postmaster's original stderr output to try to diagnose problems, not realizing/remembering that their logging configuration is set up to send log messages somewhere else. This seems particularly likely to happen in prepackaged distributions, since many packagers patch the code to change the factory-standard logging configuration to something more in line with their platform conventions. In hopes of reducing confusion, emit a LOG message about this at the point in startup where we are about to switch log output away from the original stderr, providing a pointer to where to look instead. This message will appear as the last thing in the original stderr output. (We might later also try to emit such link messages when logging parameters are changed on-the-fly; but that case seems to be both noticeably harder to do nicely, and much less frequently a problem in practice.) Per discussion, back-patch to 9.3 but not further. | 13 August 2013, 19:24:56 UTC |
| 7cf5540 | Bruce Momjian | 13 August 2013, 16:51:26 UTC | 9.3 release notes: move foreign table item Move item about foreign data wrappers supporting inserts/updates/deletes to object manipulation. Backpatch to 9.3. From Etsuro Fujita | 13 August 2013, 16:51:26 UTC |
| 7f288a2 | Peter Eisentraut | 11 August 2013, 13:17:04 UTC | PL/Python: Adjust the regression tests for Python 3.3 Similar to 2cfb1c6f77734db81b6e74bcae630f93b94f69be, the order in which dictionary elements are printed is not reliable. This reappeared in the tests of the string representation of result objects. Reduce the test case to one result set column so that there is no question of order. | 11 August 2013, 13:17:04 UTC |
| 2edaee0 | Bruce Momjian | 10 August 2013, 01:46:13 UTC | docs: mention Julian is midnight _UTC_ (Yes, there was no UTC back then, but we compute it that way.) Backpatch to 9.3. | 10 August 2013, 01:46:13 UTC |
| 95b5f5e | Bruce Momjian | 09 August 2013, 23:25:51 UTC | Docs: Document to_*() Julian values are integers Backpatch to 9.3. Per request from Marc Dahn | 09 August 2013, 23:25:51 UTC |
| 646cbc1 | Fujii Masao | 09 August 2013, 13:14:26 UTC | Document how auto_explain.log_timing can be changed. | 09 August 2013, 13:14:26 UTC |
| 595f52f | Peter Eisentraut | 09 August 2013, 11:59:53 UTC | Message punctuation and pluralization fixes | 09 August 2013, 11:59:53 UTC |
| 92d003f | Peter Eisentraut | 08 August 2013, 02:48:40 UTC | Message style improvements | 08 August 2013, 02:53:50 UTC |
| b5a20ab | Tom Lane | 03 August 2013, 16:39:51 UTC | Make sure float4in/float8in accept all standard spellings of "infinity". The C99 and POSIX standards require strtod() to accept all these spellings (case-insensitively): "inf", "+inf", "-inf", "infinity", "+infinity", "-infinity". However, pre-C99 systems might accept only some or none of these, and apparently Windows still doesn't accept "inf". To avoid surprising cross-platform behavioral differences, manually check for each of these spellings if strtod() fails. We were previously handling just "infinity" and "-infinity" that way, but since C99 is most of the world now, it seems likely that applications are expecting all these spellings to work. Per bug #8355 from Basil Peace. It turns out this fix won't actually resolve his problem, because Python isn't being this careful; but that doesn't mean we shouldn't be. | 03 August 2013, 16:40:36 UTC |
| 69fdc95 | Alvaro Herrera | 02 August 2013, 18:34:56 UTC | Fix old visibility bug in HeapTupleSatisfiesDirty If a tuple is locked but not updated by a concurrent transaction, HeapTupleSatisfiesDirty would return that transaction's Xid in xmax, causing callers to wait on it, when it is not necessary (in fact, if the other transaction had used a multixact instead of a plain Xid to mark the tuple, HeapTupleSatisfiesDirty would have behave differently and *not* returned the Xmax). This bug was introduced in commit 3f7fbf85dc5b42, dated December 1998, so it's almost 15 years old now. However, it's hard to see this misbehave, because before we had NOWAIT the only consequence of this is that transactions would wait for slightly more time than necessary; so it's not surprising that this hasn't been reported yet. Craig Ringer and Andres Freund | 02 August 2013, 21:06:50 UTC |
| 0009462 | Alvaro Herrera | 02 August 2013, 16:49:03 UTC | Fix crash in error report of invalid tuple lock My tweak of these error messages in commit c359a1b082 contained the thinko that a query would always have rowMarks set for a query containing a locking clause. Not so: when declaring a cursor, for instance, rowMarks isn't set at the point we're checking, so we'd be dereferencing a NULL pointer. The fix is to pass the lock strength to the function raising the error, instead of trying to reverse-engineer it. The result not only is more robust, but it also seems cleaner overall. Per report from Robert Haas. | 02 August 2013, 17:37:40 UTC |
| 820739c | Stephen Frost | 01 August 2013, 19:42:07 UTC | Improve handling of pthread_mutex_lock error case We should really be reporting a useful error along with returning a valid return code if pthread_mutex_lock() throws an error for some reason. Add that and back-patch to 9.0 as the prior patch. Pointed out by Alvaro Herrera | 01 August 2013, 19:43:40 UTC |
| 5575438 | Stephen Frost | 01 August 2013, 05:15:45 UTC | Add locking around SSL_context usage in libpq I've been working with Nick Phillips on an issue he ran into when trying to use threads with SSL client certificates. As it turns out, the call in initialize_SSL() to SSL_CTX_use_certificate_chain_file() will modify our SSL_context without any protection from other threads also calling that function or being at some other point and trying to read from SSL_context. To protect against this, I've written up the attached (based on an initial patch from Nick and much subsequent discussion) which puts locks around SSL_CTX_use_certificate_chain_file() and all of the other users of SSL_context which weren't already protected. Nick Phillips, much reworked by Stephen Frost Back-patch to 9.0 where we started loading the cert directly instead of using a callback. | 01 August 2013, 05:23:49 UTC |
| 603c4a9 | Alvaro Herrera | 31 July 2013, 21:57:15 UTC | Fix mis-indented lines Per Coverity | 31 July 2013, 22:00:58 UTC |
| 5d9951a | Tom Lane | 31 July 2013, 15:31:26 UTC | Fix regexp_matches() handling of zero-length matches. We'd find the same match twice if it was of zero length and not immediately adjacent to the previous match. replace_text_regexp() got similar cases right, so adjust this search logic to match that. Note that even though the regexp_split_to_xxx() functions share this code, they did not display equivalent misbehavior, because the second match would be considered degenerate and ignored. Jeevan Chalke, with some cosmetic changes by me. | 31 July 2013, 15:31:26 UTC |
| fe136ba | Fujii Masao | 31 July 2013, 13:36:39 UTC | Fix inaccurate description of tablespace. Currently we don't need to update the pg_tablespace catalog after redefining the symbolic links to the tablespaces because pg_tablespace.spclocation column was removed in PostgreSQL 9.2. Back patch to 9.2 where pg_tablespace.spclocation was removed. Ian Barwick, with minor change by me. | 31 July 2013, 13:36:39 UTC |
| 9a78f66 | Noah Misch | 30 July 2013, 22:36:52 UTC | Restore REINDEX constraint validation. Refactoring as part of commit 8ceb24568054232696dddc1166a8563bc78c900a had the unintended effect of making REINDEX TABLE and REINDEX DATABASE no longer validate constraints enforced by the indexes in question; REINDEX INDEX still did so. Indexes marked invalid remained so, and constraint violations arising from data corruption went undetected. Back-patch to 9.0, like the causative commit. | 30 July 2013, 22:39:31 UTC |
| e243e3a | Bruce Momjian | 30 July 2013, 13:23:31 UTC | pg_upgrade: clarify C comment about Windows thread struct pointers Backpatch to 9.3 to keep source trees consistent. | 30 July 2013, 13:23:31 UTC |
| 8cbf8df | Tom Lane | 29 July 2013, 14:42:41 UTC | Fix contrib/cube and contrib/seg to build with bison 3.0. These modules used the YYPARSE_PARAM macro, which has been deprecated by the bison folk since 1.875, and which they finally removed in 3.0. Adjust the code to use the replacement facility, %parse-param, which is a much better solution anyway since it allows specification of the type of the extra parser parameter. We can thus get rid of a lot of unsightly casting. Back-patch to all active branches, since somebody might try to build a back branch with up-to-date tools. | 29 July 2013, 14:42:41 UTC |
| faee8f1 | Peter Eisentraut | 28 July 2013, 10:59:09 UTC | Message style improvements | 28 July 2013, 10:59:09 UTC |
| d83940a | Bruce Momjian | 27 July 2013, 19:00:58 UTC | pg_upgrade: fix -j race condition on Windows Pg_Upgrade cannot write the command string to the log file and then call system() to write to the same file without causing occasional file-share errors on Windows. So instead, write the command string to the log file after system(), in those cases. Backpatch to 9.3. | 27 July 2013, 19:00:58 UTC |
| 61edd52 | Bruce Momjian | 26 July 2013, 17:52:01 UTC | pg_upgrade docs: don't use cluster for binary/lib In a few cases, pg_upgrade said old/new cluster location when it meant old/new Postgres install location, so fix those. Per private email report | 26 July 2013, 17:52:01 UTC |
