From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Thomas Lockhart <lockhart(at)fourpalms(dot)org> |
Cc: | Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Did someone break CVS? |
Date: | 2002-08-05 14:58:26 |
Message-ID: | 21323.1028559506@sss.pgh.pa.us |
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?
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
From | Date | Subject | |
---|---|---|---|
Next Message | Joe Conway | 2002-08-05 15:12:27 | Re: anonymous composite types for Table Functions (aka |
Previous Message | Tom Lane | 2002-08-05 14:06:37 | Re: Wacky OID idea |