Re: [GENERAL] Insert result does not match record count

From: Vik Fearing <vik(dot)fearing(at)dalibo(dot)com>
To: Bruce Momjian <bruce(at)momjian(dot)us>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Andres Freund <andres(at)2ndquadrant(dot)com>, Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, Natalie Wenz <nataliewenz(at)ebureau(dot)com>, "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org>, PG Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [GENERAL] Insert result does not match record count
Date: 2014-02-01 01:25:16
Message-ID: 52EC4CFC.1060905@dalibo.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

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(at)momjian(dot)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

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Bruce Momjian 2014-02-01 01:26:52 Re: [GENERAL] Insert result does not match record count
Previous Message Michael Paquier 2014-02-01 01:00:47 Re: pg_basebackup on standby node failed

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2014-02-01 01:26:52 Re: [GENERAL] Insert result does not match record count
Previous Message Bruce Momjian 2014-02-01 01:22:22 Re: Compression of full-page-writes