Hello, Andrew.
I hope you don't mind I've added this patch to CommitFest:
https://commitfest.postgresql.org/action/patch_view?id=606
You wrote:
AC On 6/3/2011 10:26 PM, Andrew Chernow wrote:
I disagree -- I think the fix is a one-liner. line 446:
if (tup_num == res-ntups
On Thu, Jun 9, 2011 at 12:48 AM, Pavel Golub pa...@microolap.com wrote:
it's a feature addition I approve of. I think serious consideration
ought to be given to locking down returned results so PQsetvalue refuses
to touch them, instead. Otherwise we're likely to find ourselves unable
to make
On Mon, Jun 6, 2011 at 1:42 PM, Merlin Moncure mmonc...@gmail.com wrote:
On Mon, Jun 6, 2011 at 7:09 AM, Pavel Golub pa...@microolap.com wrote:
Sorry for delay in answer. Yeah, I'm glad to. Should I apply this
patch by myself?
sure, run it against your test case and make sure it works. if so,
Merlin Moncure mmonc...@gmail.com writes:
I went ahead and tested andrew's second patch -- can we get this
reviewed and committed?
Add it to the upcoming commitfest.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
On Wed, Jun 8, 2011 at 10:18 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Merlin Moncure mmonc...@gmail.com writes:
I went ahead and tested andrew's second patch -- can we get this
reviewed and committed?
Add it to the upcoming commitfest.
It's a client crashing bug in PQsetvalue that goes back to
Merlin Moncure mmonc...@gmail.com writes:
On Wed, Jun 8, 2011 at 10:18 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Merlin Moncure mmonc...@gmail.com writes:
I went ahead and tested andrew's second patch -- can we get this
reviewed and committed?
Add it to the upcoming commitfest.
It's a client
On Wed, Jun 8, 2011 at 11:03 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Merlin Moncure mmonc...@gmail.com writes:
On Wed, Jun 8, 2011 at 10:18 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Merlin Moncure mmonc...@gmail.com writes:
I went ahead and tested andrew's second patch -- can we get this
reviewed
On 6/8/2011 12:03 PM, Tom Lane wrote:
Merlin Moncuremmonc...@gmail.com writes:
On Wed, Jun 8, 2011 at 10:18 AM, Tom Lanet...@sss.pgh.pa.us wrote:
Merlin Moncuremmonc...@gmail.com writes:
I went ahead and tested andrew's second patch -- can we get this
reviewed and committed?
Add it to
Hello, Merlin.
You wrote:
MM On Wed, Jun 8, 2011 at 11:03 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Merlin Moncure mmonc...@gmail.com writes:
On Wed, Jun 8, 2011 at 10:18 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Merlin Moncure mmonc...@gmail.com writes:
I went ahead and tested andrew's second
Hello, guys.
You wrote:
MM On Fri, Jun 3, 2011 at 10:36 PM, Andrew Chernow a...@esilo.com wrote:
On 6/3/2011 10:26 PM, Andrew Chernow wrote:
I disagree -- I think the fix is a one-liner. line 446:
if (tup_num == res-ntups !res-tuples[tup_num])
should just become
if (tup_num == res-ntups)
On Mon, Jun 6, 2011 at 7:09 AM, Pavel Golub pa...@microolap.com wrote:
Sorry for delay in answer. Yeah, I'm glad to. Should I apply this
patch by myself?
sure, run it against your test case and make sure it works. if so, we
can pass it up the chain of command (hopefully as context diff).
On Fri, Jun 3, 2011 at 10:36 PM, Andrew Chernow a...@esilo.com wrote:
On 6/3/2011 10:26 PM, Andrew Chernow wrote:
I disagree -- I think the fix is a one-liner. line 446:
if (tup_num == res-ntups !res-tuples[tup_num])
should just become
if (tup_num == res-ntups)
also the memset of the
Hello.
Reproduced under Windows XP SP3 using Visual C++ 2008 and Delphi. If
PQsetvalue is called with second parameter equals to PQntuples then
memory corruption appears. But it should grow internal tuples array
and populate the last item with provided data. Please see the code:
#include
On 6/3/2011 3:03 PM, Pavel Golub wrote:
Hello.
Reproduced under Windows XP SP3 using Visual C++ 2008 and Delphi. If
PQsetvalue is called with second parameter equals to PQntuples then
memory corruption appears. But it should grow internal tuples array
and populate the last item with provided
On Fri, Jun 3, 2011 at 2:03 PM, Pavel Golub pa...@microolap.com wrote:
Hello.
Reproduced under Windows XP SP3 using Visual C++ 2008 and Delphi. If
PQsetvalue is called with second parameter equals to PQntuples then
memory corruption appears. But it should grow internal tuples array
and
On Fri, Jun 3, 2011 at 3:06 PM, Andrew Chernow a...@esilo.com wrote:
On 6/3/2011 3:03 PM, Pavel Golub wrote:
Hello.
Reproduced under Windows XP SP3 using Visual C++ 2008 and Delphi. If
PQsetvalue is called with second parameter equals to PQntuples then
memory corruption appears. But it
On 6/3/2011 4:06 PM, Andrew Chernow wrote:
On 6/3/2011 3:03 PM, Pavel Golub wrote:
Hello.
Reproduced under Windows XP SP3 using Visual C++ 2008 and Delphi. If
PQsetvalue is called with second parameter equals to PQntuples then
memory corruption appears. But it should grow internal tuples array
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
On Fri, Jun 3, 2011 at 3:38 PM, Andrew Chernow a...@esilo.com wrote:
Eeekks. Found an additional bug. PQsetvalue only allocates the actual
tuple if the provided tup_num equals the number of tuples (append) and that
slot is NULL. This is wrong. The original idea behind PQsetvalue was you
On 6/3/2011 5:54 PM, Merlin Moncure wrote:
On Fri, Jun 3, 2011 at 3:38 PM, Andrew Chernowa...@esilo.com wrote:
Eeekks. Found an additional bug. PQsetvalue only allocates the actual
tuple if the provided tup_num equals the number of tuples (append) and that
slot is NULL. This is wrong. The
On Fri, Jun 3, 2011 at 6:22 PM, Andrew Chernow a...@esilo.com wrote:
Actually, the original idea, as I stated UT, was to allow adding tuples in
any order as well as overwriting them. Obviously lost that while trying to
get libpqtypes working, which only appends.
Well, that may or not be the
On 6/3/2011 7:14 PM, Merlin Moncure wrote:
On Fri, Jun 3, 2011 at 6:22 PM, Andrew Chernowa...@esilo.com wrote:
Actually, the original idea, as I stated UT, was to allow adding tuples in
any order as well as overwriting them. Obviously lost that while trying to
get libpqtypes working, which
I disagree -- I think the fix is a one-liner. line 446:
if (tup_num == res-ntups !res-tuples[tup_num])
should just become
if (tup_num == res-ntups)
also the memset of the tuple slots when the slot array is expanded can
be removed. (in addition, the array tuple array expansion should
really be
On 6/3/2011 10:26 PM, Andrew Chernow wrote:
I disagree -- I think the fix is a one-liner. line 446:
if (tup_num == res-ntups !res-tuples[tup_num])
should just become
if (tup_num == res-ntups)
also the memset of the tuple slots when the slot array is expanded can
be removed. (in addition, the
24 matches
Mail list logo
