Skip site navigation (1) Skip section navigation (2)

Re: ANALYZE crashes randomly

From: Olivier Hubaut <olivier(at)scmbb(dot)ulb(dot)ac(dot)be>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PgSQL Admin <pgsql-admin(at)postgresql(dot)org>
Subject: Re: ANALYZE crashes randomly
Date: 2004-02-20 14:15:53
Message-ID: 40361699.10605@scmbb.ulb.ac.be (view raw or flat)
Thread:
Lists: pgsql-admin
Tom Lane wrote:

> Olivier Hubaut <olivier(at)scmbb(dot)ulb(dot)ac(dot)be> writes:
> 
>>>>PANIC:  could not open transaction-commit log directory 
>>>>(/usr/local/pgsql/annot/pg_clog): Too many open files
> 
> 
>>But it's amazing to me that i had to reduce it so much as the postmaster 
>>is almost the only application running on this server.
> 
> 
> Oh, wait, I bet you are running into the per-process open file limit not
> the kernel limit.  The per-process limit is usually pretty low on
> Darwin, and checking the code I see
> 
>     xldir = opendir(XLogDir);
>     if (xldir == NULL)
>         ereport(PANIC,
>                 (errcode_for_file_access(),
>             errmsg("could not open transaction log directory \"%s\": %m",
>                    XLogDir)));
> 
> That is, we don't have a fallback path to recover when the error is
> ENFILE or EMFILE.  Looks to me like all the opendir() calls in the
> backend ought to be handled by fd.c with code to release other open
> files at need.
> 
> In the meantime, though, it seems fishy that Postgres wouldn't have
> detected and allowed for the per-process file limit.  Which version of
> OS X did you say you were using?
> 
> 			regards, tom lane
> 
> 
Once again, thanks for your help

For the moment, we are running on OS X 10.2.8 but we'll change soon for 
OS X 10.3

-- 
Signature en cours de maintenance,
Veuillez patienter...

In response to

pgsql-admin by date

Next:From: Joe MaldonadoDate: 2004-02-20 15:03:11
Subject: database clustering
Previous:From: Tom LaneDate: 2004-02-20 14:03:32
Subject: Re: ANALYZE crashes randomly

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group