Re: reindexdb dying with SIGPIPE on 8.2.5

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Torsten Luettgert <t(dot)luettgert(at)pressestimmen(dot)de>
Cc: pgsql-admin(at)postgresql(dot)org
Subject: Re: reindexdb dying with SIGPIPE on 8.2.5
Date: 2008-08-07 03:37:29
Message-ID: 20908.1218080249@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin

Torsten Luettgert <t(dot)luettgert(at)pressestimmen(dot)de> writes:
> Now, this works fine about 50% of the time, but on some machines, the
> reindexdb dies from a SIGPIPE signal. The logs look like this:

> Aug 3 04:08:10 prospero postgres[27101]: [1-1] NOTICE: table
> "pg_class" was reindexed
> Aug 3 04:08:11 prospero postgres[27101]: [2-1] NOTICE: table
> "sql_sizing" was reindexed
> Aug 3 04:08:11 prospero postgres[27101]: [3-1] LOG: could not send
> data to client: Broken pipe
> Aug 3 04:08:11 prospero postgres[27101]: [4-1] NOTICE: table
> "sql_sizing_profiles" was reindexed
> Aug 3 04:08:11 prospero postgres[27101]: [5-1] NOTICE: table
> "sql_features" was reindexed

> So, it looks to me like the REINDEX command is completed, but the
> reindexdb tool dies.

Yeah, so it would seem.

> We did get a notice to increase max_fsm_pages at first though, so
> we increased it with good margin, but the SIGPIPE problem persists.

max_fsm_pages isn't going to have any impact on a client's behavior.

I'm wondering if the reindexdb is being run under a restrictive ulimit
setting, or something else that would prevent it from just sitting and
waiting.

Is there anything in the kernel log at the time of the failure report?

regards, tom lane

In response to

Responses

Browse pgsql-admin by date

  From Date Subject
Next Message H. Hall 2008-08-07 09:39:31 Re: Managing connections
Previous Message FM 2008-08-06 18:50:46 speeding up backup with -Fc -Z ?