On 04/08/2015 07:27 AM, Michael Paquier wrote:
> On Wed, Apr 8, 2015 at 3:54 AM, Heikki Linnakangas wrote:
>> On 04/07/2015 09:18 AM, Michael Paquier wrote:
>>> I have noticed as well that getCopyStart() in fe-protocol3.c needs to
>>> be made a little bit smarter to make the difference between an OOM and
>>> the not-enough-data type of problem.
>>
>> Yeah. getParamDescription still has the issue, with your patch.
>
> Check.
There are still a few parseInput subroutines that have similar issues.
In fe-protocol2.c:
* pqGetErrorNotice2 returns EOF if there is not enough data, but also on
OOM. The caller assumes it's because not enough data.
* getRowDescriptions() is the same, although it sets conn->errorMessage
on OOM.
* getAnotherTuple() is the same, but it also skips over the received
data, so you won't get stuck. So maybe that's OK.
* getNotify() just drops any NOTIFY messages on OOM. Perhaps that's OK..
The corresponding functions in fe-protocol3.c are pretty much identical,
with the same issues. In addition:
* getParameterStatus will act as if the parameter value was "out of
memory". That'll be fun for something like client_encoding or
standard_conforming_strings. Would be good to use a small char[100]
variable, in stack, if it fits, and only use malloc for larger values.
That would cover all the common variables that need to be machine-parsed.
- Heikki