Re: signed short fd - Mailing list pgsql-hackers

From Tom Lane
Subject Re: signed short fd
Date
Msg-id 5908.1110783974@sss.pgh.pa.us
Whole thread Raw
In response to signed short fd  ("Qingqing Zhou" <zhouqq@cs.toronto.edu>)
Responses Re: signed short fd  (pgsql@mohawksoft.com)
List pgsql-hackers
"Qingqing Zhou" <zhouqq@cs.toronto.edu> writes:
> So is there any special reason we don't worry that convert an integer to
> short will not lose data?

It's not possible for that to happen unless the user has set
max_files_per_process to more than 32K, so I'm not particularly
worried.  Do you know of any platforms that would be unlikely to
go belly-up with dozens or hundreds of PG backends each trying to use
tens of thousands of open files?

While I agree that storing this as int16 is micro-optimization,
I don't see it as likely to be a problem in the foreseeable
future.  If it makes you feel better, we can constrain
max_files_per_process to 32K in guc.c.

> Maybe we make the assumption that all OS will
> implement "fd" as an array index

The POSIX spec requires open() to assign fd's consecutively from zero.
http://www.opengroup.org/onlinepubs/007908799/xsh/open.html
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [BUGS] We are not following the spec for HAVING without GROUP
Next
From: Bruno Wolff III
Date:
Subject: Re: [BUGS] We are not following the spec for HAVING without GROUP