On Mon, Nov 28, 2011 at 4:44 PM, Alvaro Herrera
alvhe...@commandprompt.com 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
On Mon, Nov 28, 2011 at 8:40 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Alvaro Herrera alvhe...@commandprompt.com 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
Excerpts from Tom Lane's message of mar nov 22 01:14:33 -0300 2011:
Alvaro Herrera alvhe...@alvh.no-ip.org 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
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.
There
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 of the
Alvaro Herrera alvhe...@commandprompt.com 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
Excerpts from Tom Lane's message of mar nov 22 01:14:33 -0300 2011:
Alvaro Herrera alvhe...@alvh.no-ip.org 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
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
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 this
Noah Misch n...@leadboat.com 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
Alvaro Herrera alvhe...@alvh.no-ip.org 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
I wrote:
Noah Misch n...@leadboat.com 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
12 matches
Mail list logo
