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?
It would actually be better to limit XLogDir to MAXPGPATH minus a couple
dozen characters, to ensure that filenames formed in the style above
cannot overflow their buffer variables.
BTW: was there anything in that patch that ensured XLogDir would be
an absolute path? A relative path is guaranteed not to work.
regards, tom lane
