On Tue, Apr 24, 2012 at 09:08:36AM +0100, Simon Riggs wrote:
> On Sat, Apr 21, 2012 at 5:52 PM, Noah Misch 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
> > transaction has
On Sat, Apr 21, 2012 at 5:52 PM, Noah Misch 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
> transaction has
> > 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
>
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
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 VACUU
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
