Re: [HACKERS] an older problem? hash table out of memory - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [HACKERS] an older problem? hash table out of memory
Date
Msg-id 1645.925861514@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] an older problem? hash table out of memory  (Bruce Momjian <maillist@candle.pha.pa.us>)
List pgsql-hackers
Bruce Momjian <maillist@candle.pha.pa.us> writes:
> Here they are.  Can you properly fix them?  Looks like good news that I
> found one of the ones you found.  The others may be OK:

Is that all?  Great, I was afraid we had some major problems lurking.

> ./backend/commands/view.c:    snprintf(buf, strlen(viewName) + 5, "_RET%s", viewName);

This one is OK since viewName is passed in (and is valid, we hope).

> ./backend/executor/nodeHash.c:    snprintf(tempname, strlen(tempname), "HJ%d.%d", (int) MyProcPid, hjtmpcnt);

This is the one I found.  I'm still working on nodeHash but hope to
commit fixes in the next day or so.

> ./backend/libpq/pqcomm.c:            snprintf(PQerrormsg + strlen(PQerrormsg), ERROR_MSG_LENGTH,

This is a bit bogus --- ERROR_MSG_LENGTH is the overall size of
PQerrormsg, but we're concatenating to what's already in the buffer, so
snprintf's limit should really be ERROR_MSG_LENGTH - strlen(PQerrormsg).
I applied a patch for consistency's sake, although I doubt this
statement could ever overrun the buffer in practice.
        regards, tom lane


pgsql-hackers by date:

Previous
From: The Hermit Hacker
Date:
Subject: Re: [HACKERS] Mirror mess... (urgent)
Next
From: Christian
Date:
Subject: 6.4.2 core dumping.