Re: Did someone break CVS? - Mailing list pgsql-hackers

From ngpg@grymmjack.com
Subject Re: Did someone break CVS?
Date
Msg-id Xns92617484EFC9C9wn7t0983uom3iu23n@64.49.215.80
Whole thread Raw
In response to Re: Did someone break CVS?  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
> Thomas Lockhart <lockhart@fourpalms.org> writes:
>> Is there a design pattern that would ask us to enforce that length
>> limit? If so, I'd be happy to do so; if not, it doesn't much matter...
> 
> Well, the issue is that the backend is just full of code like
> 
>     char        tmppath[MAXPGPATH];
> 
>     snprintf(tmppath, MAXPGPATH, "%s/xlogtemp.%d",
>              XLogDir, (int) getpid());
> 
> I suppose we could run around and try to replace every single such
> occurrence with dynamically-sized buffers, but it seems hardly worth the
> trouble --- and if you want a positive argument, I'd prefer not to
> introduce another potential source of elogs (namely out-of-memory)
> into code segments that run as critical sections, as some of the xlog
> manipulation code does.  Any elog there becomes a database panic.  Is
> it worth taking such a risk to eliminate a limit that *no one* has ever
> complained about?

If that one person did exist, would it not be possible for them to just 
increase the value of MAXPGPATH and recompile?


pgsql-hackers by date:

Previous
From: "Ulrich Neumann"
Date:
Subject: PostgreSQL 7.2.1 on NetWare
Next
From: Tom Lane
Date:
Subject: Re: FUNC_MAX_ARGS benchmarks