Skip site navigation (1) Skip section navigation (2)

Re: Check for failed memory allocations in libpq

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Dave Allen <daveallen(at)acm(dot)org>
Cc: pgsql-patches(at)postgresql(dot)org
Subject: Re: Check for failed memory allocations in libpq
Date: 2003-07-31 20:48:27
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-patches
Dave Allen <daveallen(at)acm(dot)org> writes:
>> You sure you aren't just trading one misbehavior for another?

> Apologies if I missed anything, but I thought I fixed any callers of
> PQmakeEmptyPQresult that weren't already checking (parseInput and
> getRowDescriptions were the only ones).

Well, I'm concerned about the global implications.  For instance, I
think making parseInput simply return on malloc failure *without doing
any more* will convert out-of-memory from a core dump into an infinite
loop; which is hardly an improvement.  (See PQgetResult for one example
of a place that will loop till it gets something.)

I'd be the first to admit that libpq's error handling isn't very good,
but I think fixing it will take some wholesale rework of the internal
calling conventions, not a few lines of localized patches.

Having said that, though, CVS tip does have some progress on this
matter; it will usually behave reasonably when it runs out of memory for
a query result.  If you'd like to pursue the matter, please pull down
CVS tip and see what you can do with it.  The patch as given would not
be much use to us anyway because of the changes since 7.3...

			regards, tom lane

In response to

pgsql-patches by date

Next:From: Bruce MomjianDate: 2003-07-31 21:11:51
Subject: Re: Autoconf test for incompatible version of flex
Previous:From: Dave AllenDate: 2003-07-31 20:33:32
Subject: Re: Check for failed memory allocations in libpq

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group