Re: Tracking down log segment corruption - Mailing list pgsql-general

From Tom Lane
Subject Re: Tracking down log segment corruption
Date
Msg-id 14283.1272823801@sss.pgh.pa.us
Whole thread Raw
In response to Re: Tracking down log segment corruption  (Gordon Shannon <gordo169@gmail.com>)
Responses Re: Tracking down log segment corruption  (Gordon Shannon <gordo169@gmail.com>)
List 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 by date:

Previous
From: Andy
Date:
Subject: Re: PostgreSQL vs. Microsoft SQL server
Next
From: Dave Page
Date:
Subject: Re: postgres crashes - could not reattach to shared memory