Re: Tracking down log segment corruption

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Tracking down log segment corruption
Дата
Msg-id 14283.1272823801@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Tracking down log segment corruption  (Gordon Shannon <gordo169@gmail.com>)
Ответы Re: Tracking down log segment corruption  (Gordon Shannon <gordo169@gmail.com>)
Список pgsql-general
Gordon Shannon <gordo169@gmail.com> writes:
> Interesting. There is no pg_class entry for 22362.

No, this would be a pg_database row with that OID.  But it looks like
you found the relevant index anyway.

> ... There is, however, an
> entry for that filenode. It's an index I created Sat AM, about 6AM.
> ...
> - This morning, I was doing some table maintenance on the master and
> discovered I had created this table and its indexes in the wrong tablespace.
> I wanted the table in ts29, but had it in ts30.  Vice versa for the
> indexes.  So I moved them. This is from my command history:

> alter index cts_20100501_natural_uk set tablespace ts30;
> alter index cts_20100501_pkey set tablespace ts30;
> alter index cts_20100501_topic_date_nk set tablespace ts30;
> alter index cts_20100501_updated_nk set tablespace ts30;
> alter table cts_20100501 set tablespace ts29;

> These commands worked fine on the master, yet this seems suspiciously
> relevant.

Yeah, perhaps so.  What time did the failure on the standby occur (how
long after you did those moves)?  Is it reasonable to assume that this
was the first subsequent access to the index?

            regards, tom lane

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

Предыдущее
От: Andy
Дата:
Сообщение: Re: PostgreSQL vs. Microsoft SQL server
Следующее
От: Dave Page
Дата:
Сообщение: Re: postgres crashes - could not reattach to shared memory