From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: [HACKERS] Path-length follies |
Date: | 1999-10-23 22:28:34 |
Message-ID: | 2329.940717714@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us> writes:
>> Does anyone have a better idea? Is it worth trying to extract a
>> system limit on pathlength during configure, rather than leaving
>> MAXPGPATH as a manual configuration item --- and if so, exactly how
>> should configure go about it?
> I don't like the 128 or 256 numbers, but isn't there a predefined place
> for this value in standard system headers?
There are too many of 'em, actually --- I had never realized this
before, but there are three or four *different* "standard" symbols that
all purport to be max pathlength. On my box they actually have three
different values, which doesn't leave a warm feeling in the stomach.
As I was just commenting off-list, we do not need to enforce the local
kernel's pathlength limit --- it's perfectly capable of doing that for
itself. All we really need to do is make sure we are not a bottleneck
preventing reasonable usage. So, although I was thinking last night
that a configure test might be a good idea, I now believe it's a waste
of cycles. (It could even be counterproductive, if it seized on a
bogusly small value, as _POSIX_PATH_MAX appears to be on both of the
systems I've checked.) Let's just set the value at something generous
like 1K and forget it. But we should use a consistent, tweakable-in-
one-place value, just in case.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 1999-10-23 23:07:19 | Re: [HACKERS] Neverending query on 6.5.2 over Solaris 2.5.1 |
Previous Message | Stephen Kogge | 1999-10-23 20:30:51 | Re: [HACKERS] RFC: Industrial-strength logging |