Alvaro Herrera writes:
> Excerpts from Jeff Amiel's message of mar jun 08 09:26:25 -0400 2010:
>> Jun 7 15:05:01 db-1 postgres[9334]: [ID 748848 local0.crit] [3989781-1]
>> 2010-06-07 15:05:01.087 CDT9334PANIC: right sibling 169 of block 168 is
>> not next child of 249 in index "sl_seqlog_
On 6/8/10 2:03 PM, "Alvaro Herrera" wrote:
>
> I've seen this problem (and others) in a high-load environment. Not
> Slony related though.
>
> I wrote a small tool to check btree index files for consistency problems
> such as this one, by parsing pg_filedump output. I've seen strange
> thin
Excerpts from Jeff Amiel's message of mar jun 08 09:26:25 -0400 2010:
> Not looking for help...just putting some data out there.
>
> 2 previous crashes caused by corrupt slony indexes
>
> http://archives.postgresql.org/pgsql-general/2010-02/msg00022.php
>
> http://archives.postgresql.org/pgsql-g
Excerpts from Jeff Amiel's message of mar jun 08 14:19:02 -0400 2010:
> " It seems preferable to configure autovacuum to avoid vacuum
> Slony-I-managed configuration tables. "
>
>
> HmmmI don't do this.
> Surely this is not relative to my corrupt indexes2 attempted vacuums on
> same inde
On 6/8/10 1:15 PM, "Jaime Casanova" wrote:
> On Tue, Jun 8, 2010 at 12:49 PM, Jeff Amiel wrote:
>>
>> Does Slony manage it's own vacuuming separate from postgres' autovacuum?
>>
>
> Yes it does: http://www.slony.info/documentation/maintenance.html
" It seems preferable to configure aut
On Tue, Jun 8, 2010 at 12:49 PM, Jeff Amiel wrote:
>
> Does Slony manage it's own vacuuming separate from postgres' autovacuum?
>
Yes it does: http://www.slony.info/documentation/maintenance.html
--
Jaime Casanova www.2ndQuadrant.com
Soporte y capacitación de PostgreSQL
--
Sent vi
On 6/8/10 12:56 PM, "Tom Lane" wrote:
> Jeff Amiel writes:
>> On a side note, I am 100% sure that autovacuum was disabled when I brought
>> the database back up after the core dump(s). However, minutes after
>> restarting, some of my larger tables started getting vacuumed by pgsql user.
>> A
Jeff Amiel writes:
> On a side note, I am 100% sure that autovacuum was disabled when I brought
> the database back up after the core dump(s). However, minutes after
> restarting, some of my larger tables started getting vacuumed by pgsql user.
> Any way that a vacuum would kick off for a particu
On 6/8/10 11:23 AM, "Tom Lane" wrote:
> In your original report you mentioned that the next autovacuum attempt
> on the same table succeeded without incident. Has that been true each
> time? I wonder whether this is some transient state, rather than actual
> corruption that you need to REINDEX
Jeff Amiel writes:
> New one yesterday.
> Jun 7 15:05:01 db-1 postgres[9334]: [ID 748848 local0.crit] [3989781-1]
> 2010-06-07 15:05:01.087 CDT9334PANIC: right sibling 169 of block 168 is
> not next child of 249 in index "sl_seqlog_idx"
In your original report you mentioned that the next
On Tue, Jun 8, 2010 at 9:26 AM, Jeff Amiel wrote:
> That being said, the fact that each time this has happened, it has been a
> slony index that has been corrupt, I find it 'odd'. While I can't imagine a
> bug in slony corrupting postgres indexes...and I can't imagine a bug in
> postgres corru
Not looking for help...just putting some data out there.
2 previous crashes caused by corrupt slony indexes
http://archives.postgresql.org/pgsql-general/2010-02/msg00022.php
http://archives.postgresql.org/pgsql-general/2009-12/msg01172.php
New one yesterday.
Jun 7 15:05:01 db-1 postgres[9334]
12 matches
Mail list logo
