Torsten Luettgert <t.luettgert@pressestimmen.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