Was wondering if there's a similar bug which gets triggered while using
VACUUM FULL. See for instance this thread:
http://postgresql.1045698.n5.nabble.com/index-corruption-in-PG-8-3-13-td4257589.html
This issue has been reported on-off from time to time and in most cases
VACUUM or
On Sat, Apr 21, 2012 at 5:52 PM, Noah Misch n...@leadboat.com wrote:
As I mentioned[1] peripherally back in November, that algorithm has been
insufficient since the introduction of non-XID-bearing transactions in
PostgreSQL 8.3. Such transactions do not restrain RecentXmin. If no running
On Tue, Apr 24, 2012 at 09:08:36AM +0100, Simon Riggs wrote:
On Sat, Apr 21, 2012 at 5:52 PM, Noah Misch n...@leadboat.com wrote:
The fix is to compare the stored XID to RecentGlobalXmin, not RecentXmin.
?We
already use RecentGlobalXmin when wal_level = hot_standby. ?If no running
On Sun, Apr 22, 2012 at 12:13:34AM +0530, Nikhil Sontakke wrote:
Was wondering if there's a similar bug which gets triggered while using
VACUUM FULL. See for instance this thread:
http://postgresql.1045698.n5.nabble.com/index-corruption-in-PG-8-3-13-td4257589.html
This issue has been
For the sake of concurrency, our B-tree implementation has a phased process
for reusing empty pages. Excerpting from nbtree/README:
A deleted page cannot be reclaimed immediately, since there may be other
processes waiting to reference it (ie, search processes that just left
the
Hi Noah,
Was wondering if there's a similar bug which gets triggered while using
VACUUM FULL. See for instance this thread:
http://postgresql.1045698.n5.nabble.com/index-corruption-in-PG-8-3-13-td4257589.html
This issue has been reported on-off from time to time and in most cases
VACUUM or
