Thom's memory leak

On my laptop I've managed to create 1,001 local chained (one-to-one) streaming-only (meaning no archive directory) asynchronous replication instances. The output of the status of the list is here: https://gist.github.com/darkixion/5694200 I also tested the promotion of the 1st standby to see if it would cope with propagation to the final 1,000th standby, and it worked flawlessly. This didn't work on my copy of Linux Mint without some adjustments to the kernel semaphores values, and it does take a while for all the standbys in the chain to reach full recovery. However, promotion propagation is very fast. Try it for yourself (if you have enough RAM that is). You may find it quicker to use my pg_rep_test tool . Just don't do this manually... it'll take far too long. Thanks to Heikki for putting in the changes that made this archiveless cascading replication possible. :) Update: some figures So looking at the logs, it's clear why it takes so long for all ...

This year's accepted Google Summer of Code projects have been published . Among them are 3 accepted proposals for PostgreSQL which not only will be fine addition to PostgreSQL's set of features, but also helps introduce new students to our community for hopefully long-term contributions. The projects that will be worked on are: Cube extension improvement (Stas Kelvich) Indexes on the cube data type (in the "cube" extension) tend to be on the large size, meaning maintenance of and accessing these indexes is expensive. The improvements this project aims to implement are in reducing the cost of indexes on cube data by using r-tree structures. In addition to this, PostgreSQL's relatively new K-Nearest Neighbour framework would serve to allow the creation of ordering operators for retrieving sorted data directly from the index, and ordering operators for kNN with different spatial norms. UPDATE ... RETURNING OLD (Karol Trzcionka) PostgreSQL can perform UPDATE...