PostgreSQL 9.0.2 commit log

commit   : 178ca03f1cc81fd9ceb6c62b8d90397023d0d8a2    
  
author   : Marc G. Fournier <[email protected]>    
date     : Mon, 13 Dec 2010 22:55:50 -0400    
  
committer: Marc G. Fournier <[email protected]>    
date     : Mon, 13 Dec 2010 22:55:50 -0400    

commit   : 7fa690f8b97dc1568968922ff40591bf048147e7    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 13 Dec 2010 20:21:55 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 13 Dec 2010 20:21:55 -0500    

commit   : c8a154e3f887457d777c77e36ad4c8024e1292d1    
  
author   : Peter Eisentraut <[email protected]>    
date     : Mon, 13 Dec 2010 23:20:00 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Mon, 13 Dec 2010 23:20:00 +0200    

commit   : dc124a541079b34a92d16649883ec929f4a5dec9    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 13 Dec 2010 12:41:57 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 13 Dec 2010 12:41:57 -0500    

commit   : 14a58a1c954103c376754d485e26455dec466c9b    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 10 Dec 2010 11:33:38 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 10 Dec 2010 11:33:38 -0500    

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.  

commit   : a804a23e7af0e075b88e7b03bfd9b0f22d2657b2    
  
author   : Simon Riggs <[email protected]>    
date     : Fri, 10 Dec 2010 06:59:33 +0000    
  
committer: Simon Riggs <[email protected]>    
date     : Fri, 10 Dec 2010 06:59:33 +0000    

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  

commit   : 2ffcb0cb6a5bf97de22f0ce58f55537ce1c87653    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 9 Dec 2010 13:03:11 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 9 Dec 2010 13:03:11 -0500    

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.  

commit   : 87eadd7e3d6f5581d5b4cb8083212a323050e388    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 8 Dec 2010 20:01:14 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 8 Dec 2010 20:01:14 -0500    

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.  

commit   : 799d0b4b9ede51c629149185e4058c52117cd231    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Tue, 7 Dec 2010 09:23:30 +0100    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Tue, 7 Dec 2010 09:23:30 +0100    

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.  

commit   : a65b29794a394afdea78a3ee367ca8fd373788e3    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 6 Dec 2010 22:55:51 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 6 Dec 2010 22:55:51 -0500    

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.  

commit   : e116bcf290ed699c4a7273c5d4b385d1fcea5aa0    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Mon, 6 Dec 2010 12:36:26 +0100    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Mon, 6 Dec 2010 12:36:26 +0100    

commit   : 0a85bb237e63c0e0634ed029cbc4916b0eceeea4    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 1 Dec 2010 00:53:23 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 1 Dec 2010 00:53:23 -0500    

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.  

commit   : 09425f89e764beabbdd30cc877b3de96f5d3d2b9    
  
author   : Simon Riggs <[email protected]>    
date     : Mon, 29 Nov 2010 01:10:56 +0000    
  
committer: Simon Riggs <[email protected]>    
date     : Mon, 29 Nov 2010 01:10:56 +0000    

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

commit   : e6fa73e87a3f3aeb4694ad3d20a179fb76e12ce1    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 26 Nov 2010 15:20:55 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 26 Nov 2010 15:20:55 -0500    

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 <[email protected]>    
date     : Thu, 25 Nov 2010 19:40:58 +0900    
  
committer: Itagaki Takahiro <[email protected]>    
date     : Thu, 25 Nov 2010 19:40:58 +0900    

commit   : b5efc094042638154d74fdb1e8344ae0ba977617    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 19 Nov 2010 22:28:25 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 19 Nov 2010 22:28:25 -0500    

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.  

commit   : b11accc9a9ade1b5da3ba0791b725dd29f9abeb7    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 18 Nov 2010 17:06:57 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 18 Nov 2010 17:06:57 -0500    

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.  

commit   : d3f62f232fc874efb22a06b2fd370eefa5f62790    
  
author   : Magnus Hagander <[email protected]>    
date     : Tue, 16 Nov 2010 12:40:56 +0100    
  
committer: Magnus Hagander <[email protected]>    
date     : Tue, 16 Nov 2010 12:40:56 +0100    

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.  

commit   : 821bb177227be9287f8fd50c2398c7bc5c3929e3    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Tue, 16 Nov 2010 11:02:11 +0200    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Tue, 16 Nov 2010 11:02:11 +0200    

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

commit   : e086197aaa8de484dafcb1cc991640980e252d70    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 15 Nov 2010 14:27:00 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 15 Nov 2010 14:27:00 -0500    

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 <[email protected]>    
date     : Mon, 15 Nov 2010 09:31:23 +0000    
  
committer: Simon Riggs <[email protected]>    
date     : Mon, 15 Nov 2010 09:31:23 +0000    

commit   : e6b3802518ef46d12c45a9a43594bdb0ae650afc    
  
author   : Robert Haas <[email protected]>    
date     : Sun, 14 Nov 2010 21:27:34 -0500    
  
committer: Robert Haas <[email protected]>    
date     : Sun, 14 Nov 2010 21:27:34 -0500    

Alexander Korotkov  

commit   : c350b01e2f72249ce6bcb642e0ee6730838b0cfe    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 14 Nov 2010 15:57:42 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 14 Nov 2010 15:57:42 -0500    

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.  

commit   : 9f65a874ebf86291ca1f7920f74f6c9d6d20a213    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 13 Nov 2010 00:34:50 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Sat, 13 Nov 2010 00:34:50 -0500    

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.  

commit   : 9e4b2139db4ce101c2d655325a4835d8e12f1c03    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 12 Nov 2010 15:14:51 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 12 Nov 2010 15:14:51 -0500    

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.  

commit   : bda2856514c2bcf5c1f74e9aa679faf985f491d2    
  
author   : Peter Eisentraut <[email protected]>    
date     : Fri, 12 Nov 2010 21:25:57 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Fri, 12 Nov 2010 21:25:57 +0200    

commit   : 533073cf2321bb9fd3ec983443e41b7040f2771b    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Fri, 12 Nov 2010 15:19:14 +0200    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Fri, 12 Nov 2010 15:19:14 +0200    

commit   : 9dba66c0e5248ad70f0a45b1b39ece6b1f549d53    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Thu, 11 Nov 2010 19:21:49 +0200    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Thu, 11 Nov 2010 19:21:49 +0200    

Jeff Davis, with a little tweaking by me.  

commit   : 01670b8be6caca08fd99f4cc3927d94a8d8ca694    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 10 Nov 2010 16:51:39 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 10 Nov 2010 16:51:39 -0500    

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.  

commit   : ad2a292dc39cf160e54bcf5088d2106a15950771    
  
author   : Bruce Momjian <[email protected]>    
date     : Wed, 10 Nov 2010 14:33:37 +0000    
  
committer: Bruce Momjian <[email protected]>    
date     : Wed, 10 Nov 2010 14:33:37 +0000    

commit   : 244cc39d854a10b782840473678a2d40fd42cc06    
  
author   : Itagaki Takahiro <[email protected]>    
date     : Wed, 10 Nov 2010 12:17:43 +0900    
  
committer: Itagaki Takahiro <[email protected]>    
date     : Wed, 10 Nov 2010 12:17:43 +0900    

commit   : 9743783d5a036ba837d1879b575756ad05cda935    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 9 Nov 2010 11:28:18 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 9 Nov 2010 11:28:18 -0500    

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.  

commit   : 39a67533975c8cbadf3d755216cea3ec2c3ce64c    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Tue, 9 Nov 2010 17:40:09 +0200    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Tue, 9 Nov 2010 17:40:09 +0200    

Backpatch to 8.3 where the heap rewrite code was introduced.  

commit   : e55e4c9ced485b44be9e100bbe54546a3272ddae    
  
author   : Alvaro Herrera <[email protected]>    
date     : Tue, 9 Nov 2010 11:00:56 -0300    
  
committer: Alvaro Herrera <[email protected]>    
date     : Tue, 9 Nov 2010 11:00:56 -0300    

Author: Marti Raudsepp <[email protected]>  

commit   : c6c67505e4b7dc4951a149493882dd2debe0766c    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 8 Nov 2010 22:14:55 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 8 Nov 2010 22:14:55 -0500    

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.  

commit   : 0f0294930420133c7254ac0e3b3a40b8ad74dc80    
  
author   : Alvaro Herrera <[email protected]>    
date     : Mon, 8 Nov 2010 18:35:42 -0300    
  
committer: Alvaro Herrera <[email protected]>    
date     : Mon, 8 Nov 2010 18:35:42 -0300    

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.  

commit   : ba007262a7661234588b1ebe297e3a95924ba587    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 6 Nov 2010 22:59:09 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sat, 6 Nov 2010 22:59:09 -0400    

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.  

commit   : fb9042f77232bf30e3743e87fbcd1f1e2b29bde5    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 3 Nov 2010 13:41:53 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 3 Nov 2010 13:41:53 -0400    

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.  

commit   : 3f36070d72a54b94096e6853b185eb677a658369    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 2 Nov 2010 18:45:44 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 2 Nov 2010 18:45:44 -0400    

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.  

commit   : 368e44f6a54a81d036fb85ea0f4544a233d7cf11    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 2 Nov 2010 17:31:54 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 2 Nov 2010 17:31:54 -0400    

Problem reported, and cause identified, by Hernan Gonzalez.  

commit   : e84bf651216a80c1d0c0d14901dea244c6a333ab    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 2 Nov 2010 17:15:13 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 2 Nov 2010 17:15:13 -0400    

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.  

commit   : 77459eba8cb32aa0e1e1736a3f3b08b8e8dde181    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Tue, 2 Nov 2010 11:23:43 +0200    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Tue, 2 Nov 2010 11:23:43 +0200    

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.  

commit   : 268fecc62cde08c89952c26cb01db8f04a2dc88d    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Mon, 1 Nov 2010 09:56:45 +0200    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Mon, 1 Nov 2010 09:56:45 +0200    

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

commit   : 381d6a05aecbade0bf536325ace36f1507da042b    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 28 Oct 2010 13:01:01 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 28 Oct 2010 13:01:01 -0400    

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.  

commit   : 4dd158ec04dd1798a1bf3ff71152ac7c6e142962    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Wed, 27 Oct 2010 20:03:00 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Wed, 27 Oct 2010 20:03:00 +0300    

commit   : 6319c35d5b3e7e0a2cdc832503815741d9ad5eb5    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 26 Oct 2010 22:23:16 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 26 Oct 2010 22:23:16 -0400    

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.  

commit   : b887f7b3526627d22d01d0cdb74a21ead08934a7    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Tue, 26 Oct 2010 22:50:31 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Tue, 26 Oct 2010 22:50:31 +0300    

commit   : 3d7905d21a45ae5790ad3ae5487d56de5cf39110    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Tue, 26 Oct 2010 21:15:42 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Tue, 26 Oct 2010 21:15:42 +0300    

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

commit   : 113082c6579f3310ecaa6a5cba2e24a0ce325b5d    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 25 Oct 2010 13:04:42 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 25 Oct 2010 13:04:42 -0400    

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.  

commit   : ae9ac79b39d5ce0c28e13c47261d925b61701b66    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Fri, 22 Oct 2010 18:38:31 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Fri, 22 Oct 2010 18:38:31 +0300    

commit   : 143b8cbceec0d15dd5c747e2c45a4b0a762af6f0    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Fri, 22 Oct 2010 17:37:38 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Fri, 22 Oct 2010 17:37:38 +0300    

commit   : eda3a62f98a6d81727f82a9ae13718343549ca7d    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 20 Oct 2010 17:05:15 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 20 Oct 2010 17:05:15 -0400    

commit   : 686ad321641b50f75536faf8c6156cec700eb936    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Wed, 20 Oct 2010 22:20:33 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Wed, 20 Oct 2010 22:20:33 +0300    

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

commit   : c98cd9bdb618794643b670c8240c0aad213340c7    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 20 Oct 2010 12:48:57 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 20 Oct 2010 12:48:57 -0400    

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.  

commit   : 72ba1f2c67e058755e21165ad8efcb0849abacd5    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 20 Oct 2010 00:55:03 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 20 Oct 2010 00:55:03 -0400    

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.  

commit   : 486187ae847b203d0c9e0d1c1b482104c659e557    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 19 Oct 2010 21:53:08 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 19 Oct 2010 21:53:08 -0400    

commit   : 01b4bb44fe0b0687ec5578a5fa72527080291c28    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 19 Oct 2010 15:08:47 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 19 Oct 2010 15:08:47 -0400    

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).  

commit   : 80a65c05777ef2b05dfe3a276568cad438fb804d    
  
author   : Bruce Momjian <[email protected]>    
date     : Tue, 19 Oct 2010 15:52:44 +0000    
  
committer: Bruce Momjian <[email protected]>    
date     : Tue, 19 Oct 2010 15:52:44 +0000    

commit   : 6f609199df2c8d38ed0391180a2ff467333ae57c    
  
author   : Bruce Momjian <[email protected]>    
date     : Tue, 19 Oct 2010 14:58:03 +0000    
  
committer: Bruce Momjian <[email protected]>    
date     : Tue, 19 Oct 2010 14:58:03 +0000    

commit   : fc8470ed4d7aca48b14521168d607ef8bbdcf0e1    
  
author   : Bruce Momjian <[email protected]>    
date     : Tue, 19 Oct 2010 02:55:58 +0000    
  
committer: Bruce Momjian <[email protected]>    
date     : Tue, 19 Oct 2010 02:55:58 +0000    

Backpatch to 9.0.X.  

commit   : 377e6e97eb59f14ca91ef38785c3dbc36e3111cd    
  
author   : Bruce Momjian <[email protected]>    
date     : Mon, 18 Oct 2010 18:51:28 +0000    
  
committer: Bruce Momjian <[email protected]>    
date     : Mon, 18 Oct 2010 18:51:28 +0000    

commit   : 02b1f04770f09abe8a78260a9f0c43fe2dc3ab8b    
  
author   : Bruce Momjian <[email protected]>    
date     : Mon, 18 Oct 2010 18:16:45 +0000    
  
committer: Bruce Momjian <[email protected]>    
date     : Mon, 18 Oct 2010 18:16:45 +0000    

commit   : eed33cdd83a6f8693c40268adc39d6d65fff8b23    
  
author   : Magnus Hagander <[email protected]>    
date     : Sun, 17 Oct 2010 16:36:54 +0200    
  
committer: Magnus Hagander <[email protected]>    
date     : Sun, 17 Oct 2010 16:36:54 +0200    

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.  

commit   : 24d446b56959f4449b5c78520a954ea0bbb517b8    
  
author   : Magnus Hagander <[email protected]>    
date     : Fri, 15 Oct 2010 16:59:12 +0200    
  
committer: Magnus Hagander <[email protected]>    
date     : Fri, 15 Oct 2010 16:59:12 +0200    

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.  

commit   : 4bc8d9dc90bb98b915d9900a7c1a9482214814bb    
  
author   : Simon Riggs <[email protected]>    
date     : Fri, 15 Oct 2010 10:19:10 +0100    
  
committer: Simon Riggs <[email protected]>    
date     : Fri, 15 Oct 2010 10:19:10 +0100    

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

commit   : fb9bb9f4cfb6bb9a00673d267e0fe08e7cec9eff    
  
author   : Robert Haas <[email protected]>    
date     : Thu, 14 Oct 2010 19:12:24 -0400    
  
committer: Robert Haas <[email protected]>    
date     : Thu, 14 Oct 2010 19:12:24 -0400    

commit   : d609ff3ced934ec46f1200ab5adf9f26b995cd4a    
  
author   : Simon Riggs <[email protected]>    
date     : Thu, 14 Oct 2010 23:23:26 +0100    
  
committer: Simon Riggs <[email protected]>    
date     : Thu, 14 Oct 2010 23:23:26 +0100    

Brendan Jurd  

commit   : 071f810c982be5b3789ff408b51e2777ae32ebdd    
  
author   : Peter Eisentraut <[email protected]>    
date     : Thu, 14 Oct 2010 20:36:42 +0300    
  
committer: Peter Eisentraut <[email protected]>    
date     : Thu, 14 Oct 2010 20:36:42 +0300    

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.  

commit   : 392e01a03a36bee3665fc1d9317f904cc8d2cda1    
  
author   : Simon Riggs <[email protected]>    
date     : Thu, 14 Oct 2010 19:13:09 +0100    
  
committer: Simon Riggs <[email protected]>    
date     : Thu, 14 Oct 2010 19:13:09 +0100    

Fujii Masao  

commit   : 86d4cc4a2acedeacdaa3535113cb90dabbd752ea    
  
author   : Michael Meskes <[email protected]>    
date     : Thu, 14 Oct 2010 17:49:01 +0200    
  
committer: Michael Meskes <[email protected]>    
date     : Thu, 14 Oct 2010 17:49:01 +0200    

commit   : ef76230c2719ab2f8809bc0d94389ebe41a6a249    
  
author   : Peter Eisentraut <[email protected]>    
date     : Wed, 13 Oct 2010 20:05:16 +0300    
  
committer: Peter Eisentraut <[email protected]>    
date     : Wed, 13 Oct 2010 20:05:16 +0300    

commit   : 67120d35e28b85bbb4d10f4568f6e3b85c8e0460    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 11 Oct 2010 22:16:46 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 11 Oct 2010 22:16:46 -0400    

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

commit   : 3b6eb752d99360e4e21ddff2c3edf750ab9b026a    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 11 Oct 2010 19:04:44 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 11 Oct 2010 19:04:44 -0400    

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.  

commit   : ffeca98cec9671c55a0693de30b50f839c0732be    
  
author   : Robert Haas <[email protected]>    
date     : Fri, 8 Oct 2010 22:59:48 -0400    
  
committer: Robert Haas <[email protected]>    
date     : Fri, 8 Oct 2010 22:59:48 -0400    

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

commit   : 57f475271d82c2e5443b25c1cbc7fdc07b9e5b91    
  
author   : Robert Haas <[email protected]>    
date     : Fri, 8 Oct 2010 09:15:17 -0400    
  
committer: Robert Haas <[email protected]>    
date     : Fri, 8 Oct 2010 09:15:17 -0400    

commit   : c1db5296429a8f26929c1afe5c9d217ba65a3b53    
  
author   : Robert Haas <[email protected]>    
date     : Thu, 7 Oct 2010 12:19:03 -0400    
  
committer: Robert Haas <[email protected]>    
date     : Thu, 7 Oct 2010 12:19:03 -0400    

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.  

commit   : 7887db612cefcc9f2648f3248cba1f3904c80b3b    
  
author   : Simon Riggs <[email protected]>    
date     : Wed, 6 Oct 2010 00:20:54 +0100    
  
committer: Simon Riggs <[email protected]>    
date     : Wed, 6 Oct 2010 00:20:54 +0100    

Spotted by Bernd Helmle  

commit   : 6f1e6b9ccd6f7515063d466ef5ad1bd38b347be1    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 5 Oct 2010 18:48:20 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 5 Oct 2010 18:48:20 -0400    

commit   : abcea94ee3679e5cf4ed81c69439f2b27d17bbc4    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 2 Oct 2010 20:02:33 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sat, 2 Oct 2010 20:02:33 -0400    

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.  

commit   : 060f576d0b32ed69ba7317c9a310016ac0d4df02    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 2 Oct 2010 18:40:28 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sat, 2 Oct 2010 18:40:28 -0400    

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  

commit   : 8178d9480aeedfa20157bb98e21b5f3b6eb8a957    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 2 Oct 2010 18:21:41 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sat, 2 Oct 2010 18:21:41 -0400    

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.