From: | Andrew Chernow <ac(at)esilo(dot)com> |
---|---|
To: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
Cc: | Pavel Golub <pavel(at)microolap(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Error in PQsetvalue |
Date: | 2011-06-03 20:48:22 |
Message-ID: | 4DE94896.1060405@esilo.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
>>
>> At first glance (have not tested this theory), looks like pqAddTuple()
>> doesn't zero the newly allocated tuples slots like PQsetvalue() does.
>> PQsetvalue is depending on the unassigned tuple table slots to be NULL to
>> detect when a tuple must be allocated. Around line 446 on fe-exec.c. I
>> never tested this case since libpqtypes never tried to call PQsetvalue on a
>> PGresult created by the standard libpq library.
>>
>> The solution I see would be to zero the new table slots within pqAddTuple.
>> Any other ideas?
>
> It might not be necessary to do that. AIUI the tuple table slot guard
> is there essentially to let setval know if it needs to allocate tuple
> attributes, which always has to be done after a new tuple is created
> after a set.
Trying to append a tuple to a libpq generated PGresult will core dump
due to the pqAddTuple issue, unless the append operation forces
PQsetvalue to grow the tuple table; in which case new elements are
zero'd. OP attempted to append.
res = PQexec("returns 2 tuples");
PQsetvalue(res, PQntuples(res), ...);
--
Andrew Chernow
eSilo, LLC
global backup
http://www.esilo.com/
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2011-06-03 20:50:40 | Re: SIREAD lock versus ACCESS EXCLUSIVE lock |
Previous Message | Kevin Grittner | 2011-06-03 20:44:03 | Re: SIREAD lock versus ACCESS EXCLUSIVE lock |