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&& !res->t
On Thu, Jun 9, 2011 at 12:48 AM, Pavel Golub 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 future
Hello, Merlin.
You wrote:
MM> On Wed, Jun 8, 2011 at 11:03 AM, Tom Lane wrote:
>> Merlin Moncure writes:
>>> On Wed, Jun 8, 2011 at 10:18 AM, Tom Lane wrote:
Merlin Moncure writes:
> I went ahead and tested andrew's second patch -- can we get this
> reviewed and committed?
>>
>>>
On 6/8/2011 12:03 PM, Tom Lane wrote:
Merlin Moncure writes:
On Wed, Jun 8, 2011 at 10:18 AM, Tom Lane wrote:
Merlin Moncure 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 i
On Wed, Jun 8, 2011 at 11:03 AM, Tom Lane wrote:
> Merlin Moncure writes:
>> On Wed, Jun 8, 2011 at 10:18 AM, Tom Lane wrote:
>>> Merlin Moncure writes:
I went ahead and tested andrew's second patch -- can we get this
reviewed and committed?
>
>>> Add it to the upcoming commitfest.
>
Merlin Moncure writes:
> On Wed, Jun 8, 2011 at 10:18 AM, Tom Lane wrote:
>> Merlin Moncure 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 t
On Wed, Jun 8, 2011 at 10:18 AM, Tom Lane wrote:
> Merlin Moncure 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 9.0 :(. In
short (apologies
Merlin Moncure 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 changes to your subscri
On Mon, Jun 6, 2011 at 1:42 PM, Merlin Moncure wrote:
> On Mon, Jun 6, 2011 at 7:09 AM, Pavel Golub 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
On Mon, Jun 6, 2011 at 7:09 AM, Pavel Golub 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).
merlin
--
Sent via pg
Hello, guys.
You wrote:
MM> On Fri, Jun 3, 2011 at 10:36 PM, Andrew Chernow 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 (tu
On Fri, Jun 3, 2011 at 10:36 PM, Andrew Chernow 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 t
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,
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
reall
On 6/3/2011 7:14 PM, Merlin Moncure wrote:
On Fri, Jun 3, 2011 at 6:22 PM, Andrew Chernow 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.
W
On Fri, Jun 3, 2011 at 6:22 PM, Andrew Chernow 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 case, but tha
On 6/3/2011 5:54 PM, Merlin Moncure wrote:
On Fri, Jun 3, 2011 at 3:38 PM, Andrew Chernow 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
On Fri, Jun 3, 2011 at 3:38 PM, Andrew Chernow 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
> can add tupl
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 t
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
On Fri, Jun 3, 2011 at 3: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
On Fri, Jun 3, 2011 at 2: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 i
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 dat
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
#inclu
24 matches
Mail list logo
