PostgreSQL 9.0.2 commit log

Tag 9.0.2.

  
commit   : 178ca03f1cc81fd9ceb6c62b8d90397023d0d8a2    
  
author   : Marc G. Fournier <scrappy@hub.org>    
date     : Mon, 13 Dec 2010 22:55:50 -0400    
  
committer: Marc G. Fournier <scrappy@hub.org>    
date     : Mon, 13 Dec 2010 22:55:50 -0400    

Click here for diff

  
  

Update release notes for releases 9.0.2, 8.4.6, 8.3.13, 8.2.19, and 8.1.23.

  
commit   : 7fa690f8b97dc1568968922ff40591bf048147e7    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 13 Dec 2010 20:21:55 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 13 Dec 2010 20:21:55 -0500    

Click here for diff

  
  

Translation updates for release 9.0.2

  
commit   : c8a154e3f887457d777c77e36ad4c8024e1292d1    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 13 Dec 2010 23:20:00 +0200    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 13 Dec 2010 23:20:00 +0200    

Click here for diff

  
  

Update time zone data files to tzdata release 2010o: DST law changes in Fiji and Samoa. Historical corrections for Hong Kong.

  
commit   : dc124a541079b34a92d16649883ec929f4a5dec9    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 13 Dec 2010 12:41:57 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 13 Dec 2010 12:41:57 -0500    

Click here for diff

  
  

Fix efficiency problems in tuplestore_trim().

  
commit   : 14a58a1c954103c376754d485e26455dec466c9b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 10 Dec 2010 11:33:38 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 10 Dec 2010 11:33:38 -0500    

Click here for diff

  
The original coding in tuplestore_trim() was only meant to work efficiently  
in cases where each trim call deleted most of the tuples in the store.  
Which, in fact, was the pattern of the original usage with a Material node  
supporting mark/restore operations underneath a MergeJoin.  However,  
WindowAgg now uses tuplestores and it has considerably less friendly  
trimming behavior.  In particular it can attempt to trim one tuple at a  
time off a large tuplestore.  tuplestore_trim() had O(N^2) runtime in this  
situation because of repeatedly shifting its tuple pointer array.  Fix by  
avoiding shifting the array until a reasonably large number of tuples have  
been deleted.  This can waste some pointer space, but we do still reclaim  
the tuples themselves, so the percentage wastage should be pretty small.  
  
Per Jie Li's report of slow percent_rank() evaluation.  cume_dist() and  
ntile() would certainly be affected as well, along with any other window  
function that has a moving frame start and requires reading substantially  
ahead of the current row.  
  
Back-patch to 8.4, where window functions were introduced.  There's no  
need to tweak it before that.  
  

Reduce spurious Hot Standby conflicts from never-visible records. Hot Standby conflicts only with tuples that were visible at some point. So ignore tuples from aborted transactions or for tuples updated/deleted during the inserting transaction when generating the conflict transaction ids.

  
commit   : a804a23e7af0e075b88e7b03bfd9b0f22d2657b2    
  
author   : Simon Riggs <simon@2ndQuadrant.com>    
date     : Fri, 10 Dec 2010 06:59:33 +0000    
  
committer: Simon Riggs <simon@2ndQuadrant.com>    
date     : Fri, 10 Dec 2010 06:59:33 +0000    

Click here for diff

  
Following detailed analysis and test case by Noah Misch.  
Original report covered btree delete records, correctly observed  
by Heikki Linnakangas that this applies to other cases also.  
Fix covers all sources of cleanup records via common code.  
Includes additional fix compared to commit on HEAD  
  

Eliminate O(N^2) behavior in parallel restore with many blobs.

  
commit   : 2ffcb0cb6a5bf97de22f0ce58f55537ce1c87653    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 9 Dec 2010 13:03:11 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 9 Dec 2010 13:03:11 -0500    

Click here for diff

  
With hundreds of thousands of TOC entries, the repeated searches in  
reduce_dependencies() become the dominant cost.  Get rid of that searching  
by constructing reverse-dependency lists, which we can do in O(N) time  
during the fix_dependencies() preprocessing.  I chose to store the reverse  
dependencies as DumpId arrays for consistency with the forward-dependency  
representation, and keep the previously-transient tocsByDumpId[] array  
around to locate actual TOC entry structs quickly from dump IDs.  
  
While this fixes the slow case reported by Vlad Arkhipov, there is still  
a potential for O(N^2) behavior with sufficiently many tables:  
fix_dependencies itself, as well as mark_create_done and  
inhibit_data_for_failed_table, are doing repeated searches to deal with  
table-to-table-data dependencies.  Possibly this work could be extended  
to deal with that, although the latter two functions are also used in  
non-parallel restore where we currently don't run fix_dependencies.  
  
Another TODO is that we fail to parallelize restore of multiple blobs  
at all.  This appears to require changes in the archive format to fix.  
  
Back-patch to 9.0 where the problem was reported.  8.4 has potential issues  
as well; but since it doesn't create a separate TOC entry for each blob,  
it's at much less risk of having enough TOC entries to cause real problems.  
  

Force default wal_sync_method to be fdatasync on Linux.

  
commit   : 87eadd7e3d6f5581d5b4cb8083212a323050e388    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 8 Dec 2010 20:01:14 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 8 Dec 2010 20:01:14 -0500    

Click here for diff

  
Recent versions of the Linux system header files cause xlogdefs.h to  
believe that open_datasync should be the default sync method, whereas  
formerly fdatasync was the default on Linux.  open_datasync is a bad  
choice, first because it doesn't actually outperform fdatasync (in fact  
the reverse), and second because we try to use O_DIRECT with it, causing  
failures on certain filesystems (e.g., ext4 with data=journal option).  
This part of the patch is largely per a proposal from Marti Raudsepp.  
More extensive changes are likely to follow in HEAD, but this is as much  
change as we want to back-patch.  
  
Also clean up confusing code and incorrect documentation surrounding the  
fsync_writethrough option.  Those changes shouldn't result in any actual  
behavioral change, but I chose to back-patch them anyway to keep the  
branches looking similar in this area.  
  
In 9.0 and HEAD, also do some copy-editing on the WAL Reliability  
documentation section.  
  
Back-patch to all supported branches, since any of them might get used  
on modern Linux versions.  
  

Fix bugs in the hot standby known-assigned-xids tracking logic. If there’s an old transaction running in the master, and a lot of transactions have started and finished since, and a WAL-record is written in the gap between the creating the running-xacts snapshot and WAL-logging it, recovery will fail with “too many KnownAssignedXids” error. This bug was reported by Joachim Wieland on Nov 19th.

  
commit   : 799d0b4b9ede51c629149185e4058c52117cd231    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 7 Dec 2010 09:23:30 +0100    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 7 Dec 2010 09:23:30 +0100    

Click here for diff

  
In the same scenario, when fewer transactions have started so that all the  
xids fit in KnownAssignedXids despite the first bug, a more serious bug  
arises. We incorrectly initialize the clog code with the oldest still running  
transaction, and when we see the WAL record belonging to a transaction with  
an XID larger than one that committed already before the checkpoint we're  
recovering from, we zero the clog page containing the already committed  
transaction, leading to data loss.  
  
In hindsight, trying to track xids in the known-assigned-xids array before  
seeing the running-xacts record was too complicated. To fix that, hold  
XidGenLock while the running-xacts snapshot is taken and WAL-logged. That  
ensures that no transaction can begin or end in that gap, so that in recvoery  
we know that the snapshot contains all transactions running at that point in  
WAL.  
  

Add a stack overflow check to copyObject().

  
commit   : a65b29794a394afdea78a3ee367ca8fd373788e3    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 6 Dec 2010 22:55:51 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 6 Dec 2010 22:55:51 -0500    

Click here for diff

  
There are some code paths, such as SPI_execute(), where we invoke  
copyObject() on raw parse trees before doing parse analysis on them.  Since  
the bison grammar is capable of building heavily nested parsetrees while  
itself using only minimal stack depth, this means that copyObject() can be  
the front-line function that hits stack overflow before anything else does.  
Accordingly, it had better have a check_stack_depth() call.  I did a bit of  
performance testing and found that this slows down copyObject() by only a  
few percent, so the hit ought to be negligible in the context of complete  
processing of a query.  
  
Per off-list report from Toshihide Katayama.  Back-patch to all supported  
branches.  
  

Fix two typos, by Fujii Masao.

  
commit   : e116bcf290ed699c4a7273c5d4b385d1fcea5aa0    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 6 Dec 2010 12:36:26 +0100    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 6 Dec 2010 12:36:26 +0100    

Click here for diff

  
  

Prevent inlining a SQL function with multiple OUT parameters.

  
commit   : 0a85bb237e63c0e0634ed029cbc4916b0eceeea4    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 1 Dec 2010 00:53:23 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 1 Dec 2010 00:53:23 -0500    

Click here for diff

  
There were corner cases in which the planner would attempt to inline such  
a function, which would result in a failure at runtime due to loss of  
information about exactly what the result record type is.  Fix by disabling  
inlining when the function's recorded result type is RECORD.  There might  
be some sub-cases where inlining could still be allowed, but this is a  
simple and backpatchable fix, so leave refinements for another day.  
Per bug #5777 from Nate Carson.  
  
Back-patch to all supported branches.  8.1 happens to avoid a core-dump  
here, but it still does the wrong thing.  
  

Move call to GetTopTransactionId() earlier in LockAcquire(), removing an infrequently occurring race condition in Hot Standby. An xid must be assigned before a lock appears in shared memory, rather than immediately after, else GetRunningTransactionLocks() may see InvalidTransactionId, causing assertion failures during lock processing on standby.

  
commit   : 09425f89e764beabbdd30cc877b3de96f5d3d2b9    
  
author   : Simon Riggs <simon@2ndQuadrant.com>    
date     : Mon, 29 Nov 2010 01:10:56 +0000    
  
committer: Simon Riggs <simon@2ndQuadrant.com>    
date     : Mon, 29 Nov 2010 01:10:56 +0000    

Click here for diff

  
Bug report and diagnosis by Fujii Masao, fix by me.  
  

Fix significant memory leak in contrib/xml2 functions.

  
commit   : e6fa73e87a3f3aeb4694ad3d20a179fb76e12ce1    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 26 Nov 2010 15:20:55 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 26 Nov 2010 15:20:55 -0500    

Click here for diff

  
Most of the functions that execute XPath queries leaked the data structures  
created by libxml2.  This memory would not be recovered until end of  
session, so it mounts up pretty quickly in any serious use of the feature.  
Per report from Pavel Stehule, though this isn't his patch.  
  
Back-patch to all supported branches.  
  

  
commit   : 317a568c88ee92bb50238f9fe9508803bc81501c    
  
author   : Itagaki Takahiro <itagaki.takahiro@gmail.com>    
date     : Thu, 25 Nov 2010 19:40:58 +0900    
  
committer: Itagaki Takahiro <itagaki.takahiro@gmail.com>    
date     : Thu, 25 Nov 2010 19:40:58 +0900    

Click here for diff

  
  

Fix leakage of cost_limit when multiple autovacuum workers are active.

  
commit   : b5efc094042638154d74fdb1e8344ae0ba977617    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 19 Nov 2010 22:28:25 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 19 Nov 2010 22:28:25 -0500    

Click here for diff

  
When using default autovacuum_vac_cost_limit, autovac_balance_cost relied  
on VacuumCostLimit to contain the correct global value ... but after the  
first time through in a particular worker process, it didn't, because we'd  
trashed it in previous iterations.  Depending on the state of other autovac  
workers, this could result in a steady reduction of the effective  
cost_limit setting as a particular worker processed more and more tables,  
causing it to go slower and slower.  Spotted by Simon Poole (bug #5759).  
Fix by saving and restoring the GUC variables in the loop in do_autovacuum.  
  
In passing, improve a few comments.  
  
Back-patch to 8.3 ... the cost rebalancing code has been buggy since it was  
put in.  
  

Improve plpgsql’s error reporting for no-such-column cases.

  
commit   : b11accc9a9ade1b5da3ba0791b725dd29f9abeb7    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 18 Nov 2010 17:06:57 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 18 Nov 2010 17:06:57 -0500    

Click here for diff

  
Given a column reference foo.bar, where there is a composite plpgsql  
variable foo but it doesn't contain a column bar, the pre-9.0 coding would  
immediately throw a "record foo has no field bar" error.  In 9.0 the parser  
hook instead falls through to let the core parser see if it can resolve the  
reference.  If not, you get a complaint about "missing FROM-clause entry  
for table foo", which while in some sense correct isn't terribly helpful.  
Complicate things a bit so that we can throw the old error message if  
neither the core parser nor the hook are able to resolve the column  
reference, while not changing the behavior in any other case.  
Per bug #5757 from Andrey Galkin.  
  

Send paramHandle to subprocesses as 64-bit on Win64

  
commit   : d3f62f232fc874efb22a06b2fd370eefa5f62790    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Tue, 16 Nov 2010 12:40:56 +0100    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Tue, 16 Nov 2010 12:40:56 +0100    

Click here for diff

  
The handle to the shared memory segment containing startup  
parameters was sent as 32-bit even on 64-bit systems. Since  
HANDLEs appear to be allocated sequentially this shouldn't  
be a problem until we reach 2^32 open handles in the postmaster,  
but a 64-bit value should be sent across as 64-bit, and not  
zero out the top 32 bits.  
  
Noted by Tom Lane.  
  

The GiST scan algorithm uses LSNs to detect concurrent pages splits, but temporary indexes are not WAL-logged. We used a constant LSN for temporary indexes, on the assumption that we don’t need to worry about concurrent page splits in temporary indexes because they’re only visible to the current session. But that assumption is wrong, it’s possible to insert rows and split pages in the same session, while a scan is in progress. For example, by opening a cursor and fetching some rows, and INSERTing new rows before fetching some more.

  
commit   : 821bb177227be9287f8fd50c2398c7bc5c3929e3    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 16 Nov 2010 11:02:11 +0200    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 16 Nov 2010 11:02:11 +0200    

Click here for diff

  
Fix by generating fake increasing LSNs, used in place of real LSNs in  
temporary GiST indexes.  
  

Fix aboriginal mistake in plpython’s set-returning-function support.

  
commit   : e086197aaa8de484dafcb1cc991640980e252d70    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 15 Nov 2010 14:27:00 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 15 Nov 2010 14:27:00 -0500    

Click here for diff

  
We must stay in the function's SPI context until done calling the iterator  
that returns the set result.  Otherwise, any attempt to invoke SPI features  
in the python code called by the iterator will malfunction.  Diagnosis and  
patch by Jan Urbanski, per bug report from Jean-Baptiste Quenot.  
  
Back-patch to 8.2; there was no support for SRFs in previous versions of  
plpython.  
  

  
commit   : 102aeedfb9bf01b419563151846ebbd1f01f4a5f    
  
author   : Simon Riggs <simon@2ndQuadrant.com>    
date     : Mon, 15 Nov 2010 09:31:23 +0000    
  
committer: Simon Riggs <simon@2ndQuadrant.com>    
date     : Mon, 15 Nov 2010 09:31:23 +0000    

Click here for diff

  
  

Fix bug in cube picksplit algorithm.

  
commit   : e6b3802518ef46d12c45a9a43594bdb0ae650afc    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Sun, 14 Nov 2010 21:27:34 -0500    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Sun, 14 Nov 2010 21:27:34 -0500    

Click here for diff

  
Alexander Korotkov  
  

  
commit   : c350b01e2f72249ce6bcb642e0ee6730838b0cfe    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 14 Nov 2010 15:57:42 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 14 Nov 2010 15:57:42 -0500    

Click here for diff

  
We must not return any "okay to proceed" result code without having checked  
for too many children, else we might fail later on when trying to add the  
new child to one of the per-child state arrays.  It's not clear whether  
this oversight explains Stefan Kaltenbrunner's recent report, but it could  
certainly produce a similar symptom.  
  
Back-patch to 8.4; the logic was not broken before that.  
  

Add missing outfuncs.c support for struct InhRelation.

  
commit   : 9f65a874ebf86291ca1f7920f74f6c9d6d20a213    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 13 Nov 2010 00:34:50 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 13 Nov 2010 00:34:50 -0500    

Click here for diff

  
This is needed to support debug_print_parse, per report from Jon Nelson.  
Cursory testing via the regression tests suggests we aren't missing  
anything else.  
  

Fix old oversight in const-simplification of COALESCE() expressions.

  
commit   : 9e4b2139db4ce101c2d655325a4835d8e12f1c03    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 12 Nov 2010 15:14:51 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 12 Nov 2010 15:14:51 -0500    

Click here for diff

  
Once we have found a non-null constant argument, there is no need to  
examine additional arguments of the COALESCE.  The previous coding got it  
right only if the constant was in the first argument position; otherwise  
it tried to simplify following arguments too, leading to unexpected  
behavior like this:  
  
regression=# select coalesce(f1, 42, 1/0) from int4_tbl;  
ERROR:  division by zero  
  
It's a minor corner case, but a bug is a bug, so back-patch all the way.  
  

docs -> documentation

  
commit   : bda2856514c2bcf5c1f74e9aa679faf985f491d2    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 12 Nov 2010 21:25:57 +0200    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 12 Nov 2010 21:25:57 +0200    

Click here for diff

  
  

Add missing support for removing foreign data wrapper / server privileges belonging to a user at DROP OWNED BY. Foreign data wrappers and servers don’t do anything useful yet, which is why no-one has noticed, but since we have them, seems prudent to fix this. Per report from Chetan Suttraway. Backpatch to 9.0, 8.4 has the same problem but this patch didn’t apply there so I’m not going to bother.

  
commit   : 533073cf2321bb9fd3ec983443e41b7040f2771b    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 12 Nov 2010 15:19:14 +0200    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 12 Nov 2010 15:19:14 +0200    

Click here for diff

  
  

Fix bug introduced by the recent patch to check that the checkpoint redo location read from backup label file can be found: wasShutdown was set incorrectly when a backup label file was found.

  
commit   : 9dba66c0e5248ad70f0a45b1b39ece6b1f549d53    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 11 Nov 2010 19:21:49 +0200    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 11 Nov 2010 19:21:49 +0200    

Click here for diff

  
Jeff Davis, with a little tweaking by me.  
  

Fix line_construct_pm() for the case of “infinite” (DBL_MAX) slope.

  
commit   : 01670b8be6caca08fd99f4cc3927d94a8d8ca694    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 10 Nov 2010 16:51:39 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 10 Nov 2010 16:51:39 -0500    

Click here for diff

  
This code was just plain wrong: what you got was not a line through the  
given point but a line almost indistinguishable from the Y-axis, although  
not truly vertical.  The only caller that tries to use this function with  
m == DBL_MAX is dist_ps_internal for the case where the lseg is horizontal;  
it would end up producing the distance from the given point to the place  
where the lseg's line crosses the Y-axis.  That function is used by other  
operators too, so there are several operators that could compute wrong  
distances from a line segment to something else.  Per bug #5745 from  
jindiax.  
  
Back-patch to all supported branches.  
  

Mention that pg_upgrade requires compatible 3264-bit binaries.

  
commit   : ad2a292dc39cf160e54bcf5088d2106a15950771    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Wed, 10 Nov 2010 14:33:37 +0000    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Wed, 10 Nov 2010 14:33:37 +0000    

Click here for diff

  
  

Don’t use __declspec (dllimport) for PGDLLEXPORT to reduce warnings by gcc version 4 on mingw and cygwin. We don’t use dllexport here because dllexport and dllwrap don’t work well together.

  
commit   : 244cc39d854a10b782840473678a2d40fd42cc06    
  
author   : Itagaki Takahiro <itagaki.takahiro@gmail.com>    
date     : Wed, 10 Nov 2010 12:17:43 +0900    
  
committer: Itagaki Takahiro <itagaki.takahiro@gmail.com>    
date     : Wed, 10 Nov 2010 12:17:43 +0900    

Click here for diff

  
  

Repair memory leakage while ANALYZE-ing complex index expressions.

  
commit   : 9743783d5a036ba837d1879b575756ad05cda935    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 9 Nov 2010 11:28:18 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 9 Nov 2010 11:28:18 -0500    

Click here for diff

  
The general design of memory management in Postgres is that intermediate  
results computed by an expression are not freed until the end of the tuple  
cycle.  For expression indexes, ANALYZE has to re-evaluate each expression  
for each of its sample rows, and it wasn't bothering to free intermediate  
results until the end of processing of that index.  This could lead to very  
substantial leakage if the intermediate results were large, as in a recent  
example from Jakub Ouhrabka.  Fix by doing ResetExprContext for each sample  
row.  This necessitates adding a datumCopy step to ensure that the final  
expression value isn't recycled too.  Some quick testing suggests that this  
change adds at worst about 10% to the time needed to analyze a table with  
an expression index; which is annoying, but seems a tolerable price to pay  
to avoid unexpected out-of-memory problems.  
  
Back-patch to all supported branches.  
  

In rewriteheap.c (used by VACUUM FULL and CLUSTER), calculate the tuple length stored in the line pointer the same way it’s calculated in the normal heap_insert() codepath. As noted by Jeff Davis, the length stored by raw_heap_insert() included padding but the one stored by the normal codepath did not. While the mismatch seems to be harmless, inconsistency isn’t good, and the normal codepath has received a lot more testing over the years.

  
commit   : 39a67533975c8cbadf3d755216cea3ec2c3ce64c    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 9 Nov 2010 17:40:09 +0200    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 9 Nov 2010 17:40:09 +0200    

Click here for diff

  
Backpatch to 8.3 where the heap rewrite code was introduced.  
  

plpython has plpy.Error instead of plpy.ERROR

  
commit   : e55e4c9ced485b44be9e100bbe54546a3272ddae    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 9 Nov 2010 11:00:56 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 9 Nov 2010 11:00:56 -0300    

Click here for diff

  
Author: Marti Raudsepp <marti@juffo.org>  
  

Fix error handling in temp-file deletion with log_temp_files active.

  
commit   : c6c67505e4b7dc4951a149493882dd2debe0766c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 8 Nov 2010 22:14:55 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 8 Nov 2010 22:14:55 -0500    

Click here for diff

  
The original coding in FileClose() reset the file-is-temp flag before  
unlinking the file, so that if control came back through due to an error,  
it wouldn't try to unlink the file twice.  This was correct when written,  
but when the log_temp_files feature was added, the logging action was put  
in between those two steps.  An error occurring during the logging action  
--- such as a query cancel --- would result in the unlink not getting done  
at all, as in recent report from Michael Glaesemann.  
  
To fix this, make sure that we do both the stat and the unlink before doing  
anything that could conceivably CHECK_FOR_INTERRUPTS.  There is a judgment  
call here, which is which log message to emit first: if you can see only  
one, which should it be?  I chose to log unlink failure at the risk of  
losing the log_temp_files log message --- after all, if the unlink does  
fail, the temp file is still there for you to see.  
  
Back-patch to all versions that have log_temp_files.  The code was OK  
before that.  
  

Fix permanent memory leak in autovacuum launcher

  
commit   : 0f0294930420133c7254ac0e3b3a40b8ad74dc80    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 8 Nov 2010 18:35:42 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 8 Nov 2010 18:35:42 -0300    

Click here for diff

  
get_database_list was uselessly allocating its output data, along some  
created along the way, in a permanent memory context.  This didn't  
matter when autovacuum was a single, short-lived process, but now that  
the launcher is permanent, it shows up as a permanent leak.  
  
To fix, make get_database list allocate its output data in the caller's  
context, which is in charge of freeing it when appropriate; and the  
memory leaked by heap_beginscan et al is allocated in a throwaway  
transaction context.  
  

Add support for detecting register-stack overrun on IA64.

  
commit   : ba007262a7661234588b1ebe297e3a95924ba587    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 6 Nov 2010 22:59:09 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 6 Nov 2010 22:59:09 -0400    

Click here for diff

  
Per recent investigation, the register stack can grow faster than the  
regular stack depending on compiler and choice of options.  To avoid  
crashes we must check both stacks in check_stack_depth().  
  
Back-patch to all supported versions.  
  

Reduce recursion depth in recently-added regression test.

  
commit   : fb9042f77232bf30e3743e87fbcd1f1e2b29bde5    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 3 Nov 2010 13:41:53 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 3 Nov 2010 13:41:53 -0400    

Click here for diff

  
Some buildfarm members fail the test with the original depth of 10 levels,  
apparently because they are running at the minimum max_stack_depth setting  
of 100kB and using ~ 10k per recursion level.  While it might be  
interesting to try to figure out why they're eating so much stack, it isn't  
likely that any fix for that would be back-patchable.  So just change the  
test to recurse only 5 levels.  The extra levels don't prove anything  
correctness-wise anyway.  
  

Fix adjust_semi_join to be more cautious about clauseless joins.

  
commit   : 3f36070d72a54b94096e6853b185eb677a658369    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 2 Nov 2010 18:45:44 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 2 Nov 2010 18:45:44 -0400    

Click here for diff

  
It was reporting that these were fully indexed (hence cheap), when of  
course they're the exact opposite of that.  I'm not certain if the case  
would arise in practice, since a clauseless semijoin is hard to produce  
in SQL, but if it did happen we'd make some dumb decisions.  
  

Fix buffer overrun in pg_upgrade.

  
commit   : 368e44f6a54a81d036fb85ea0f4544a233d7cf11    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 2 Nov 2010 17:31:54 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 2 Nov 2010 17:31:54 -0400    

Click here for diff

  
Problem reported, and cause identified, by Hernan Gonzalez.  
  

Ensure an index that uses a whole-row Var still depends on its table.

  
commit   : e84bf651216a80c1d0c0d14901dea244c6a333ab    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 2 Nov 2010 17:15:13 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 2 Nov 2010 17:15:13 -0400    

Click here for diff

  
We failed to record any dependency on the underlying table for an index  
declared like "create index i on t (foo(t.*))".  This would create trouble  
if the table were dropped without previously dropping the index.  To fix,  
simplify some overly-cute code in index_create(), accepting the possibility  
that sometimes the whole-table dependency will be redundant.  Also document  
this hazard in dependency.c.  Per report from Kevin Grittner.  
  
In passing, prevent a core dump in pg_get_indexdef() if the index's table  
can't be found.  I came across this while experimenting with Kevin's  
example.  Not sure it's a real issue when the catalogs aren't corrupt, but  
might as well be cautious.  
  
Back-patch to all supported versions.  
  

Bootstrap WAL to begin at segment logid=0 logseg=1 (000000010000000000000001) rather than 0/0, so that we can safely use 0/0 as an invalid value. This is a more future-proof fix for the corner-case bug in streaming replication that was fixed yesterday. We had a similar corner-case bug with log/seg 0/0 back in February as well. Avoiding 0/0 as a valid value should prevent bugs like that in the future. Per Tom Lane’s idea.

  
commit   : 77459eba8cb32aa0e1e1736a3f3b08b8e8dde181    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 2 Nov 2010 11:23:43 +0200    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 2 Nov 2010 11:23:43 +0200    

Click here for diff

  
Back-patch to 9.0. Since this only affects bootstrapping, it makes no  
difference to existing installations. We don't need to worry about the  
bug in existing installations, because if you've managed to get past the  
initial base backup already, you won't hit the bug in the future either.  
  

Fix corner-case bug in tracking of latest removed WAL segment during streaming replication. We used log/seg 0/0 to indicate that no WAL segments have been removed since startup, but 0/0 is a valid value for the very first WAL segment after initdb. To make that disambiguous, store (latest removed WAL segment + 1) in the global variable.

  
commit   : 268fecc62cde08c89952c26cb01db8f04a2dc88d    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 1 Nov 2010 09:56:45 +0200    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 1 Nov 2010 09:56:45 +0200    

Click here for diff

  
Per report from Matt Chesler, also reproduced by Greg Smith.  
  

Fix plpgsql’s handling of “simple” expression evaluation.

  
commit   : 381d6a05aecbade0bf536325ace36f1507da042b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 28 Oct 2010 13:01:01 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 28 Oct 2010 13:01:01 -0400    

Click here for diff

  
In general, expression execution state trees aren't re-entrantly usable,  
since functions can store private state information in them.  
For efficiency reasons, plpgsql tries to cache and reuse state trees for  
"simple" expressions.  It can get away with that most of the time, but it  
can fail if the state tree is dirty from a previous failed execution (as  
in an example from Alvaro) or is being used recursively (as noted by me).  
  
Fix by tracking whether a state tree is in use, and falling back to the  
"non-simple" code path if so.  This results in a pretty considerable speed  
hit when the non-simple path is taken, but the available alternatives seem  
even more unpleasant because they add overhead in the simple path.  Per  
idea from Heikki.  
  
Back-patch to all supported branches.  
  

Fix long-standing segfault when accept() or one of the calls made right after accepting a connection fails, and the server is compiled with GSSAPI support. Report and patch by Alexander V. Chernikov, bug #5731.

  
commit   : 4dd158ec04dd1798a1bf3ff71152ac7c6e142962    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 27 Oct 2010 20:03:00 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 27 Oct 2010 20:03:00 +0300    

Click here for diff

  
  

Fix up some oversights in psql’s Unicode-escape support.

  
commit   : 6319c35d5b3e7e0a2cdc832503815741d9ad5eb5    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 26 Oct 2010 22:23:16 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 26 Oct 2010 22:23:16 -0400    

Click here for diff

  
Original patch failed to include new exclusive states in a switch that  
needed to include them; and also was guilty of very fuzzy thinking  
about how to handle error cases.  Per bug #5729 from Alan Choi.  
  

Note explicitly that hash indexes are also not replicated because they’re not WAL-logged. Make the notice about the lack of WAL-logging more visible by making it a . Also remove the false statement from hot standby caveats section that hash indexes are not used during hot standby.

  
commit   : b887f7b3526627d22d01d0cdb74a21ead08934a7    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 26 Oct 2010 22:50:31 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 26 Oct 2010 22:50:31 +0300    

Click here for diff

  
  

Before removing backup_label and irrevocably changing pg_control file, check that WAL file containing the checkpoint redo-location can be found. This avoids making the cluster irrecoverable if the redo location is in an earlie WAL file than the checkpoint record.

  
commit   : 3d7905d21a45ae5790ad3ae5487d56de5cf39110    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 26 Oct 2010 21:15:42 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 26 Oct 2010 21:15:42 +0300    

Click here for diff

  
Report, analysis and patch by Jeff Davis, with small changes by me.  
  

Fix inline_set_returning_function() to preserve the invalItems list properly.

  
commit   : 113082c6579f3310ecaa6a5cba2e24a0ce325b5d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 25 Oct 2010 13:04:42 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 25 Oct 2010 13:04:42 -0400    

Click here for diff

  
This avoids a possible crash when inlining a SRF whose argument list  
contains a reference to an inline-able user function.  The crash is quite  
reproducible with CLOBBER_FREED_MEMORY enabled, but would be less certain  
in a production build.  Problem introduced in 9.0 by the named-arguments  
patch, which requires invoking eval_const_expressions() before we can try  
to inline a SRF.  Per report from Brendan Jurd.  
  

Add semicolon, missed in previous patch. And update the keyword list in the docs to reflect that OFF is now unreserved. Spotted by Tom Lane.

  
commit   : ae9ac79b39d5ce0c28e13c47261d925b61701b66    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 22 Oct 2010 18:38:31 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 22 Oct 2010 18:38:31 +0300    

Click here for diff

  
  

Make OFF keyword unreserved. It’s not hard to imagine wanting to use ‘off’ as a variable or column name, and it’s not reserved in recent versions of the SQL spec either. This became particularly annoying in 9.0, before that PL/pgSQL replaced variable names in queries with parameter markers, so it was possible to use OFF and many other backend parser keywords as variable names. Because of that, backpatch to 9.0.

  
commit   : 143b8cbceec0d15dd5c747e2c45a4b0a762af6f0    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 22 Oct 2010 17:37:38 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 22 Oct 2010 17:37:38 +0300    

Click here for diff

  
  

Remove obsolete comment, per Josh Kupershmidt.

  
commit   : eda3a62f98a6d81727f82a9ae13718343549ca7d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 20 Oct 2010 17:05:15 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 20 Oct 2010 17:05:15 -0400    

Click here for diff

  
  

If pk is NULL, the backend would segfault when accessing ->algo and the following NULL check was never reached.

  
commit   : 686ad321641b50f75536faf8c6156cec700eb936    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 20 Oct 2010 22:20:33 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 20 Oct 2010 22:20:33 +0300    

Click here for diff

  
This problem was found by Coccinelle (null_ref.cocci from coccicheck).  
  
Marti Raudsepp  
  

Don’t try to fetch database name when SetTransactionIdLimit() is executed outside a transaction.

  
commit   : c98cd9bdb618794643b670c8240c0aad213340c7    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 20 Oct 2010 12:48:57 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 20 Oct 2010 12:48:57 -0400    

Click here for diff

  
This repairs brain fade in my patch of 2009-08-30: the reason we had been  
storing oldest-database name, not OID, in ShmemVariableCache was of course  
to avoid having to do a catalog lookup at times when it might be unsafe.  
  
This error explains why Aleksandr Dushein is having trouble getting out of  
an XID wraparound state in bug #5718, though not how he got into that state  
in the first place.  I suspect pg_upgrade is at fault there.  
  

Fix ecpg test building process to not generate *.dSYM junk on Macs.

  
commit   : 72ba1f2c67e058755e21165ad8efcb0849abacd5    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 20 Oct 2010 00:55:03 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 20 Oct 2010 00:55:03 -0400    

Click here for diff

  
The trick is to not try to build executables directly from .c files,  
but to always build the intermediate .o files.  For obscure reasons,  
Darwin's version of gcc will leave debug cruft behind in the first  
case but not the second.  Per complaint from Robert Haas.  
  

Update storage.sgml to describe the 9.0 tablespace directory layout.

  
commit   : 486187ae847b203d0c9e0d1c1b482104c659e557    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 19 Oct 2010 21:53:08 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 19 Oct 2010 21:53:08 -0400    

Click here for diff

  
  

Fix incorrect generation of whole-row variables in planner.

  
commit   : 01b4bb44fe0b0687ec5578a5fa72527080291c28    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 19 Oct 2010 15:08:47 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 19 Oct 2010 15:08:47 -0400    

Click here for diff

  
A couple of places in the planner need to generate whole-row Vars, and were  
cutting corners by setting vartype = RECORDOID in the Vars, even in cases  
where there's an identifiable named composite type for the RTE being  
referenced.  While we mostly got away with this, it failed when there was  
also a parser-generated whole-row reference to the same RTE, because the  
two Vars weren't equal() due to the difference in vartype.  Fix by  
providing a subroutine the planner can call to generate whole-row Vars  
the same way the parser does.  
  
Per bug #5716 from Andrew Tipton.  Back-patch to 9.0 where one of the bogus  
calls was introduced (the other one is new in HEAD).  
  

Add removal of PG_VERSION to optional old cluster deletion script. Backpatch to 9.0.X.

  
commit   : 80a65c05777ef2b05dfe3a276568cad438fb804d    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 19 Oct 2010 15:52:44 +0000    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 19 Oct 2010 15:52:44 +0000    

Click here for diff

  
  

Add mention of using tools/fsync to test fsync methods. Restructure recent wal_sync_method doc paragraph to be clearer.

  
commit   : 6f609199df2c8d38ed0391180a2ff467333ae57c    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 19 Oct 2010 14:58:03 +0000    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 19 Oct 2010 14:58:03 +0000    

Click here for diff

  
  

In pg_upgrade, rename macro EXEC_EXT to SHELL_EXT for clarity.

  
commit   : fc8470ed4d7aca48b14521168d607ef8bbdcf0e1    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 19 Oct 2010 02:55:58 +0000    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 19 Oct 2010 02:55:58 +0000    

Click here for diff

  
Backpatch to 9.0.X.  
  

Remove tab from SGML.

  
commit   : 377e6e97eb59f14ca91ef38785c3dbc36e3111cd    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 18 Oct 2010 18:51:28 +0000    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 18 Oct 2010 18:51:28 +0000    

Click here for diff

  
  

Document the tablespace directory “should” be empty, rather than “must” be empty. Because of binary migration usage, it might not be empty.

  
commit   : 02b1f04770f09abe8a78260a9f0c43fe2dc3ab8b    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 18 Oct 2010 18:16:45 +0000    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 18 Oct 2010 18:16:45 +0000    

Click here for diff

  
  

Fix msvc build for localized versions of Visual C++

  
commit   : eed33cdd83a6f8693c40268adc39d6d65fff8b23    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Sun, 17 Oct 2010 16:36:54 +0200    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Sun, 17 Oct 2010 16:36:54 +0200    

Click here for diff

  
Look only at the non-localized part of the output from "vcbuild /?",  
which is used to determine the version of Visual Studio in use. Different  
languages seem to localize different amounts of the string, but we assume  
the part "Microsoft Visual C++" won't be modified.  
  

Fix low-risk potential denial of service against RADIUS login.

  
commit   : 24d446b56959f4449b5c78520a954ea0bbb517b8    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Fri, 15 Oct 2010 16:59:12 +0200    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Fri, 15 Oct 2010 16:59:12 +0200    

Click here for diff

  
Corrupt RADIUS responses were treated as errors and not ignored  
(which the RFC2865 states they should be). This meant that a  
user with unfiltered access to the network of the PostgreSQL  
or RADIUS server could send a spoofed RADIUS response  
to the PostgreSQL server causing it to reject a valid login,  
provided the attacker could also guess (or brute-force) the  
correct port number.  
  
Fix is to simply retry the receive in a loop until the timeout  
has expired or a valid (signed by the correct RADIUS server)  
packet arrives.  
  
Reported by Alan DeKok in bug #5687.  
  

Correct WAL space calculation formula in docs.

  
commit   : 4bc8d9dc90bb98b915d9900a7c1a9482214814bb    
  
author   : Simon Riggs <simon@2ndQuadrant.com>    
date     : Fri, 15 Oct 2010 10:19:10 +0100    
  
committer: Simon Riggs <simon@2ndQuadrant.com>    
date     : Fri, 15 Oct 2010 10:19:10 +0100    

Click here for diff

  
Error pointed out by Fujii Masao, though not his patch.  
  

Add pg_user_mappings to the table of system views.

  
commit   : fb9bb9f4cfb6bb9a00673d267e0fe08e7cec9eff    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Thu, 14 Oct 2010 19:12:24 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Thu, 14 Oct 2010 19:12:24 -0400    

Click here for diff

  
  

Improvements to docs about pg_archive_cleanup and use of archives

  
commit   : d609ff3ced934ec46f1200ab5adf9f26b995cd4a    
  
author   : Simon Riggs <simon@2ndQuadrant.com>    
date     : Thu, 14 Oct 2010 23:23:26 +0100    
  
committer: Simon Riggs <simon@2ndQuadrant.com>    
date     : Thu, 14 Oct 2010 23:23:26 +0100    

Click here for diff

  
Brendan Jurd  
  

Complete the documentation of the USAGE privilege for foreign servers

  
commit   : 071f810c982be5b3789ff408b51e2777ae32ebdd    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 14 Oct 2010 20:36:42 +0300    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 14 Oct 2010 20:36:42 +0300    

Click here for diff

  
The GRANT reference page failed to mention that the USAGE privilege  
allows modifying associated user mappings, although this was already  
documented on the CREATE/ALTER/DROP USER MAPPING pages.  
  

Fix bug in comment of timeline history file.

  
commit   : 392e01a03a36bee3665fc1d9317f904cc8d2cda1    
  
author   : Simon Riggs <simon@2ndQuadrant.com>    
date     : Thu, 14 Oct 2010 19:13:09 +0100    
  
committer: Simon Riggs <simon@2ndQuadrant.com>    
date     : Thu, 14 Oct 2010 19:13:09 +0100    

Click here for diff

  
Fujii Masao  
  

Applied patch by Itagaki Takahiro to fix incorrect status calculation in ecpglib. Instead of parsing the statement just as ask the database server.

  
commit   : 86d4cc4a2acedeacdaa3535113cb90dabbd752ea    
  
author   : Michael Meskes <meskes@postgresql.org>    
date     : Thu, 14 Oct 2010 17:49:01 +0200    
  
committer: Michael Meskes <meskes@postgresql.org>    
date     : Thu, 14 Oct 2010 17:49:01 +0200    

Click here for diff

  
  

Make title capitalization consistent with surroundings

  
commit   : ef76230c2719ab2f8809bc0d94389ebe41a6a249    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 13 Oct 2010 20:05:16 +0300    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 13 Oct 2010 20:05:16 +0300    

Click here for diff

  
  

Fix plpython so that it again honors typmod while assigning to tuple fields.

  
commit   : 67120d35e28b85bbb4d10f4568f6e3b85c8e0460    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 11 Oct 2010 22:16:46 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 11 Oct 2010 22:16:46 -0400    

Click here for diff

  
This was broken in 9.0 while improving plpython's conversion behavior for  
bytea and boolean.  Per bug report from maizi.  
  

Fix assorted bugs in GIN’s WAL replay logic.

  
commit   : 3b6eb752d99360e4e21ddff2c3edf750ab9b026a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 11 Oct 2010 19:04:44 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 11 Oct 2010 19:04:44 -0400    

Click here for diff

  
The original coding was quite sloppy about handling the case where  
XLogReadBuffer fails (because the page has since been deleted).  This  
would result in either "bad buffer id: 0" or an Assert failure during  
replay, if indeed the page were no longer there.  In a couple of places  
it also neglected to check whether the change had already been applied,  
which would probably result in corrupted index contents.  I believe that  
bug #5703 is an instance of the first problem.  These issues could show up  
without replication, but only if you were unfortunate enough to crash  
between modification of a GIN index and the next checkpoint.  
  
Back-patch to 8.2, which is as far back as GIN has WAL support.  
  

Adjust EXPLAIN documentation, so that it’s not unreasonably wide.

  
commit   : ffeca98cec9671c55a0693de30b50f839c0732be    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Fri, 8 Oct 2010 22:59:48 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Fri, 8 Oct 2010 22:59:48 -0400    

Click here for diff

  
The new formatting matches what we do for COPY.  
  
Per a complaint from Bruce Momjian.  
  

Warn that views can be safely used to hide columns, but not rows.

  
commit   : 57f475271d82c2e5443b25c1cbc7fdc07b9e5b91    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Fri, 8 Oct 2010 09:15:17 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Fri, 8 Oct 2010 09:15:17 -0400    

Click here for diff

  
  

Improve WAL reliability documentation, and add more cross-references to it.

  
commit   : c1db5296429a8f26929c1afe5c9d217ba65a3b53    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Thu, 7 Oct 2010 12:19:03 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Thu, 7 Oct 2010 12:19:03 -0400    

Click here for diff

  
In particular, we are now more explicit about the fact that you may need  
wal_sync_method=fsync_writethrough for crash-safety on some platforms,  
including MaxOS X.  There's also now an explicit caution against assuming  
that the default setting of wal_sync_method is either crash-safe or best  
for performance.  
  

Correct docs for behaviour of ALTER DATABASE .. RENAME during Hot Standby. Actual behaviour did not match documented behaviour and we have agreed that it should be the docs that change.

  
commit   : 7887db612cefcc9f2648f3248cba1f3904c80b3b    
  
author   : Simon Riggs <simon@2ndQuadrant.com>    
date     : Wed, 6 Oct 2010 00:20:54 +0100    
  
committer: Simon Riggs <simon@2ndQuadrant.com>    
date     : Wed, 6 Oct 2010 00:20:54 +0100    

Click here for diff

  
Spotted by Bernd Helmle  
  

Undo some poorly-thought-out “proofreading improvements”. Per Tatsuhito Kasahara.

  
commit   : 6f1e6b9ccd6f7515063d466ef5ad1bd38b347be1    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 5 Oct 2010 18:48:20 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 5 Oct 2010 18:48:20 -0400    

Click here for diff

  
  

Behave correctly if INSERT … VALUES is decorated with additional clauses.

  
commit   : abcea94ee3679e5cf4ed81c69439f2b27d17bbc4    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 2 Oct 2010 20:02:33 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 2 Oct 2010 20:02:33 -0400    

Click here for diff

  
In versions 8.2 and up, the grammar allows attaching ORDER BY, LIMIT,  
FOR UPDATE, or WITH to VALUES, and hence to INSERT ... VALUES.  But the  
special-case code for VALUES in transformInsertStmt() wasn't expecting any  
of those, and just ignored them, leading to unexpected results.  Rather  
than complicate the special-case path, just ensure that the presence of any  
of those clauses makes us treat the query as if it had a general SELECT.  
Per report from Hitoshi Harada.  
  

Remove excess argument to open(2).

  
commit   : 060f576d0b32ed69ba7317c9a310016ac0d4df02    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 2 Oct 2010 18:40:28 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 2 Oct 2010 18:40:28 -0400    

Click here for diff

  
Many compilers don't complain about this, but some do, and it's certainly  
wrong.  Back-patch to 8.4 where the error was introduced.  
  
Mark Kirkwood  
  

Throw an appropriate error if ALTER COLUMN TYPE finds a dependent trigger.

  
commit   : 8178d9480aeedfa20157bb98e21b5f3b6eb8a957    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 2 Oct 2010 18:21:41 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 2 Oct 2010 18:21:41 -0400    

Click here for diff

  
Actually making this case work, if the column is used in the trigger's  
WHEN condition, will take some new code that probably isn't appropriate  
to back-patch.  For now, just throw a FEATURE_NOT_SUPPORTED error rather  
than allowing control to reach the "unexpected object" case.  Per bug #5688  
from Daniel Grace.  Back-patch to 9.0 where the possibility of such a  
dependency was introduced.