Hitting the nfile limit - Mailing list pgsql-hackers

From Michael Brusser
Subject Hitting the nfile limit
Date
Msg-id DEEIJKLFNJGBEMBLBAHCMEKHDFAA.michael@synchronicity.com
Whole thread Raw
In response to Re: cvs version compile error  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Hitting the nfile limit  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
We ran into problem while load-testing 7.3.2 server.
From the database log:

FATAL: cannot open /home/<some_path>/postgresql/PG_VERSION:
File table overflow

The QA engineer who ran the test claims that after server was restarted
one record on the database was missing.

We are not sure what exactly happened. He was running about 10 servers
on HP-11, hitting them with AstraLoad. Most requests would try to update
some
record on the database, most run with Serializable Isolation Level.
Apparently we managed to run out of the open file descriptors on the host
machine.

I wonder how Postgres handles this situation.
(Or power outage, or any hard system fault, at this point)

Is it possible that we really lost a record because of that?
Should we consider changing default WAL_SYNC_METHOD?

Thanks in advance,
Michael.





pgsql-hackers by date:

Previous
From: Bruno Wolff III
Date:
Subject: Compile error in current cvs (~1230 CDT July 4)
Next
From: Vincent van Leeuwen
Date:
Subject: pg_autovacuum bug and feature request