Re: Recovery inconsistencies, standby much larger than primary

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Recovery inconsistencies, standby much larger than primary
Дата
Msg-id 21858.1391202711@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Recovery inconsistencies, standby much larger than primary  (Greg Stark <stark@mit.edu>)
Ответы Re: Recovery inconsistencies, standby much larger than primary
Список pgsql-hackers
Greg Stark <stark@mit.edu> writes:
> One thing I keep coming back to is a bad ran chip setting a bit in the
> block number. But I just can't seem to get it to add up. The difference is
> not a power of two, it had happened on two different machines, and we don't
> see other weirdness on the machine. It seems like a strange coincidence it
> would happen to the same variable twice and not to other variables.

I also looked at the bit patterns for the two block numbers, and couldn't
detect any relationship.

> Unless there's some unrelated code writing through a wild pointer, possibly
> to a stack allocated object that just happens to often be that variable?

Yeah, I'd been wondering if the WAL record somehow got corrupted while
in memory (presumably after being CRC-checked).  It's a bit hard to see
how though.

Are all the bloated-on-the-slave relations indexes?  I think the most
fruitful thing to do at this point is to try to isolate the bloating
events for the other affected rels as you've done for this one.
Maybe we'll see a pattern.
        regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: Misplaced BKI entries in pg_amproc.h
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: FOR [SHARE|UPDATE] NOWAIT may still block in EvalPlanQualFetch