Re: [HACKERS] Path-length follies

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

Responses

Browse pgsql-hackers by date

  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