Received: from localhost (unknown [200.46.204.183]) by postgresql.org (Postfix) with ESMTP id 7269A64FCEA for ; Thu, 7 Aug 2008 00:37:43 -0300 (ADT) Received: from postgresql.org ([200.46.204.86]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 93852-09 for ; Thu, 7 Aug 2008 00:37:33 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by postgresql.org (Postfix) with ESMTP id 479F364FCD8 for ; Thu, 7 Aug 2008 00:37:30 -0300 (ADT) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.2/8.14.2) with ESMTP id m773bTY0020909; Wed, 6 Aug 2008 23:37:29 -0400 (EDT) To: Torsten Luettgert cc: pgsql-admin@postgresql.org Subject: Re: reindexdb dying with SIGPIPE on 8.2.5 In-reply-to: <1218035421.19154.24.camel@oberschatzi.cff> References: <1218035421.19154.24.camel@oberschatzi.cff> Comments: In-reply-to Torsten Luettgert message dated "Wed, 06 Aug 2008 17:10:21 +0200" Date: Wed, 06 Aug 2008 23:37:29 -0400 Message-ID: <20908.1218080249@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0 tagged_above=0 required=5 tests=none X-Spam-Level: X-Archive-Number: 200808/26 X-Sequence-Number: 29871 Torsten Luettgert 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