Re: Did someone break CVS?
От | ngpg@grymmjack.com |
---|---|
Тема | Re: Did someone break CVS? |
Дата | |
Msg-id | Xns92617484EFC9C9wn7t0983uom3iu23n@64.49.215.80 обсуждение исходный текст |
Ответ на | Re: Did someone break CVS? (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | 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 по дате отправления: