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
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 |
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 |