Re: Did someone break CVS?

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

In response to

Responses

Browse pgsql-hackers by date

  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