From: | ngpg(at)grymmjack(dot)com |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Did someone break CVS? |
Date: | 2002-08-05 15:26:54 |
Message-ID: | Xns92617484EFC9C9wn7t0983uom3iu23n@64.49.215.80 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> Thomas Lockhart <lockhart(at)fourpalms(dot)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?
From | Date | Subject | |
---|---|---|---|
Next Message | Neophytos Demetriou | 2002-08-05 15:34:54 | Re: Error: missing chunk number ... |
Previous Message | Ulrich Neumann | 2002-08-05 15:25:21 | PostgreSQL 7.2.1 on NetWare |