On Mon, Nov 28, 2011 at 8:40 PM, Tom Lane wrote:
> Alvaro Herrera writes:
>> I wonder if it would be worthwhile to build some sort of tool to scan
>> the heap and ensure that there are index entries for all heap items,
>> just to test the hypothesis. Not that this would enlighten on the
>> sourc
On Mon, Nov 28, 2011 at 4:44 PM, Alvaro Herrera
wrote:
> I wonder if it's related, because it seems pretty
> much the same mechanism: sometimes, a btree index insert would be
> randomly forgotten (its page write lost in vacuum, so to speak), ...
Groan.
--
Robert Haas
EnterpriseDB: http://www.en
Alvaro Herrera writes:
> I wonder if it would be worthwhile to build some sort of tool to scan
> the heap and ensure that there are index entries for all heap items,
> just to test the hypothesis. Not that this would enlighten on the
> source of the actual problem.
Seems like the hypothesis coul
Jim Nasby wrote:
> On Nov 28, 2011, at 3:44 PM, Alvaro Herrera wrote:
> > I wonder if it would be worthwhile to build some sort of tool to scan
> > the heap and ensure that there are index entries for all heap items,
> > just to test the hypothesis. Not that this would enlighten on the
> > source
On Nov 28, 2011, at 3:44 PM, Alvaro Herrera wrote:
> I wonder if it would be worthwhile to build some sort of tool to scan
> the heap and ensure that there are index entries for all heap items,
> just to test the hypothesis. Not that this would enlighten on the
> source of the actual problem.
The
Excerpts from Tom Lane's message of mar nov 22 01:14:33 -0300 2011:
> Alvaro Herrera writes:
> > We got a very strange nbtree corruption report some time ago. This was
> > a btree index on a vey high churn table -- entries are updated and
> > deleted very quickly, so the index grows very large a
Excerpts from Tom Lane's message of mar nov 22 01:14:33 -0300 2011:
> Alvaro Herrera writes:
> > ERROR: left link changed unexpectedly in block 3378 of index "index_name"
> > CONTEXT: automatic vacuum of table "table_name"
>
> > This was reported not once, but several dozens of times, by eac
I wrote:
> Noah Misch writes:
>> Just a suspicion ... when looking at the B-tree page reclamation algorithm, I
>> had a thought that the logic in _bt_page_recyclable() was obsolete as of the
>> introduction (in 8.3) of xid-free read-only transactions. A transaction
>> without a persistent xid doe
Alvaro Herrera writes:
> We got a very strange nbtree corruption report some time ago. This was
> a btree index on a vey high churn table -- entries are updated and
> deleted very quickly, so the index grows very large and also shrinks
> quickly (AFAICT this is a work queue of sorts).
> The most
Noah Misch writes:
> Just a suspicion ... when looking at the B-tree page reclamation algorithm, I
> had a thought that the logic in _bt_page_recyclable() was obsolete as of the
> introduction (in 8.3) of xid-free read-only transactions. A transaction
> without a persistent xid does not hold back
On Mon, Nov 21, 2011 at 08:00:21PM -0300, Alvaro Herrera wrote:
> We got a very strange nbtree corruption report some time ago. This was
> a btree index on a vey high churn table -- entries are updated and
> deleted very quickly, so the index grows very large and also shrinks
> quickly (AFAICT thi
Hi,
We got a very strange nbtree corruption report some time ago. This was
a btree index on a vey high churn table -- entries are updated and
deleted very quickly, so the index grows very large and also shrinks
quickly (AFAICT this is a work queue of sorts).
The most strange thing of all is tha
12 matches
Mail list logo
