Re: [HACKERS] psql & query string length

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Ansley, Michael" <Michael(dot)Ansley(at)intec(dot)co(dot)za>
Cc: "'pgsql-hackers(at)postgresql(dot)org'" <pgsql-hackers(at)postgreSQL(dot)org>
Subject: Re: [HACKERS] psql & query string length
Date: 1999-07-21 14:42:43
Message-ID: 1761.932568163@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"Ansley, Michael" <Michael(dot)Ansley(at)intec(dot)co(dot)za> writes:
> The way I have structured it, memory is reallocated (re- malloc'd, not
> realloc'd) every time the query is extended. I suspect that this is very
> inefficient,

Probably. You should normally expand by a significant amount each time
you reallocate an expansible buffer, just to avoid making too many
demands on malloc. The method I favor is to double the buffer size at
each realloc step.

> and probably causing the system to hooch after loading long.sql
> three times.

... but not doing so shouldn't cause a coredump. I bet a plain old
bug is involved here, like writing past the end of the space you do
have allocated.

> Also, what's the deal with realloc? I tried it a couple of times, but it
> really screwed me around (hence the re- malloc'ing). Or is it just a Bad
> Move to use realloc?

realloc is perfectly fine ... see above for more likely theory.

On some old pre-ANSI-standard machines, realloc(NULL, ...) does not
work, so for portability's sake you ought to only use realloc to
increase the size of an existing buffer.

regards, tom lane

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 1999-07-21 14:59:36 Re: [HACKERS] inheritance
Previous Message Tom Lane 1999-07-21 14:36:10 Re: [HACKERS] Another reason to redesign querytree representation