Re: Did someone break CVS?

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: Thomas Lockhart <lockhart@fourpalms.org>
Cc: Christopher Kings-Lynne <chriskl@familyhealth.com.au>, pgsql-hackers@postgresql.org
Date: 2002-08-05T14:58:26Z
Lists: 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?

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