Обсуждение: handling multiple file descriptors

I've been trying to figure out how postgresql handles multiple open file
descriptors. First, I have managed to find out postgresql keeps a pool of
available descriptors for general processing tasks like sorting for
example. Second, I have tried to find what kind of data structure was used
for open descriptors to tables and indices, but couldn't find where. Could
someone please let me know what kind of data structure(s) is/are used for
open file descriptors and where this is located in the code?

The reason I'm so curious about such a specific part of the code is that
this problem has often occured in my own source code. In the past, I have
used a linked list and contemplated using a hash table to manage multiple
open file descriptors. I'm therefore interested to find out what real
production systems use for this kind of problem.

Regards,
Marc Tardif

Marc Tardif <admin@wtbwts.com> writes:
> I've been trying to figure out how postgresql handles multiple open file
> descriptors. First, I have managed to find out postgresql keeps a pool of
> available descriptors for general processing tasks like sorting for
> example. Second, I have tried to find what kind of data structure was used
> for open descriptors to tables and indices, but couldn't find where. Could
> someone please let me know what kind of data structure(s) is/are used for
> open file descriptors and where this is located in the code?

See src/backend/storage/file/fd.c.  You might also find buffile.c,
in the same directory, of interest.

These modules are not simply concerned with managing kernel FDs, but
also with releasing resources during transaction abort.  Postgres'
model of error recovery is that elog(ERROR) longjmps back to the main
server loop, so routines that were aborted out of don't get to close
files, free memory, or otherwise release resources.  fd.c is responsible
for cleaning up open FDs and temporary files after that happens.
        regards, tom lane