Re: BUG #5507: missing chunk number 0 for toast value XXXXX in pg_toast_XXXXX - Mailing list pgsql-bugs

From Kevin Grittner
Subject Re: BUG #5507: missing chunk number 0 for toast value XXXXX in pg_toast_XXXXX
Date
Msg-id 4C1742DD020000250003235B@gw.wicourts.gov
Whole thread Raw
In response to Re: BUG #5507: missing chunk number 0 for toast value XXXXX in pg_toast_XXXXX  (中嶋 信二 <sinakaj@jops.co.jp>)
List pgsql-bugs
中嶋 信二<sinakaj@jops.co.jp> wrote:

> postgres is duplicated.
> Red Hat Cluster Suite watches a process of each service.
> PGDATA shares it in strage.
>
> There is the thing that a wait server started.
> A cluster began the change disposal of servers.
> Because A cluster judged a state of postgres to be a stop.
>
> I do not understand why duplex system to refer to same PGDATA was
> able to start.
> I was able to surely carry out SQL by a psql command in duplex
> system.
> I did not output log in those days.

> Two postgres that PGDATA was shared will have started
> why if it was thought that it was caused by double start.
> Is there such a precedent?
> Does a data file lead to the cause that failed?

I'm not sure I totally understand, but it sounds like you had two
postmasters running against a single data directory.  If so, that
could cause all kinds of corruption.  It's hard to see how that
could happen unless you deleted a PostgreSQL data directory, or at
least the postmaster.pid file, while an instance was running.

I would start by capturing "ps auxf" output, to be able to
understand what postgres processes were running and when they
started.  Then I would probably make sure they all got stopped.
Then I would be seriously looking at restoring from backup, unless
this was a development database which could just be recreated from
scratch.

-Kevin

pgsql-bugs by date:

Previous
From: Maxim Boguk
Date:
Subject: Re: BUG #5503: error in trigger function with dropped columns
Next
From: Chris Copeland
Date:
Subject: Re: BUG #5452: Server core dumps coming out of recovery mode