Re: Tracking down log segment corruption

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Gordon Shannon <gordo169(at)gmail(dot)com>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: Tracking down log segment corruption
Date: 2010-05-02 18:10:01
Message-ID: 14283.1272823801@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Gordon Shannon <gordo169(at)gmail(dot)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

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Dave Page 2010-05-02 18:31:56 Re: postgres crashes - could not reattach to shared memory
Previous Message Andy 2010-05-02 17:57:33 Re: PostgreSQL vs. Microsoft SQL server