Re: [HACKERS] Insert result does not match record count - Mailing list pgsql-general

From Vik Fearing
Subject Re: [HACKERS] Insert result does not match record count
Date
Msg-id 52EC4CFC.1060905@dalibo.com
Whole thread Raw
In response to Re: [HACKERS] Insert result does not match record count  (Bruce Momjian <bruce@momjian.us>)
Responses Re: [HACKERS] Insert result does not match record count  (Bruce Momjian <bruce@momjian.us>)
List pgsql-general
On 01/31/2014 10:56 PM, Bruce Momjian wrote:
> On Fri, Jan 31, 2014 at 04:38:21PM -0500, Tom Lane wrote:
>> Bruce Momjian <bruce@momjian.us> writes:
>>> On Fri, Jan 31, 2014 at 06:34:27PM +0100, Vik Fearing wrote:
>>>> Unfortunately, I gave up on it as being over my head when I noticed I
>>>> was changing the protocol itself.  I should have notified the list so
>>>> someone else could have taken over.
>>> OK, so that brings up a good question.  Can we change the protocol for
>>> this without causing major breakage?  Tom seems to indicate that it can
>>> be done for 9.4, but I thought protocol breakage was a major issue.  Are
>>> we really changing the wire protocol here, or just the type of string we
>>> can pass back to the interface?
>> What I said about it upthread was "this is effectively a protocol change,
>> albeit a pretty minor one, so I can't see back-patching it".
>>
>> The discussion in bug #7766 shows that some client-side code is likely to
>> need fixing, and that such fixing might actually be nontrivial for them.
>> So changing this in a minor release is clearly a bad idea.  But I don't
>> have a problem with widening the counters in a major release where we
>> can document it as a potential compatibility issue.
>>
>> I took a quick look and noted that CMDSTATUS_LEN and
>> COMPLETION_TAG_BUFSIZE are set to 64, and have been for quite a long time,
>> so command status string buffer sizes should not be a problem.
>>
>> I think we probably just need to widen es_processed and touch related
>> code.

Yes.

>>  Not sure what else Vik saw that needed doing.

Quite a lot, actually.  It seemed to me at the time to be a pretty big
rabbit hole.

> OK, thanks for the feedback.  I understand now.  The contents of the
> string will potentially have a larger integer, but the byte length of
> the string in the wire protocol doesn't change.
>
> Let's wait for Vik to reply and I think we can move forward.

Unfortunately, I just did some cleanup last week and removed that
branch.  Had I waited a bit more I still would have had all the work I
had done.  I'll see how quickly I can redo it to get to the part where I
got scared of what I was doing.

It will have to wait until next week though; I am currently at FOSDEM.

--
Vik



pgsql-general by date:

Previous
From: Michael Paquier
Date:
Subject: Re: pg_basebackup on standby node failed
Next
From: Bruce Momjian
Date:
Subject: Re: [HACKERS] Insert result does not match record count