Did this every go any further?
I wrote some data transformation script at work, and after seeing "with
count -2017657667" (and similar) in my scripts log I got a bit worried.
seeing else where were folks just run a full on count(*) later to check
counts but that is even MORE time and I was think
Vik Fearing writes:
> Without re-doing the work, my IRC logs show that I was bothered by this
> in src/backend/tcop/postgres.c:
> max_rows = pq_getmsgint(&input_message, 4);
> I needed to change max_rows to int64 which meant I had to change
> pq_getmsgint to pq_getmsgint64 wh
On 02/01/2014 02:26 AM, Bruce Momjian wrote:
> On Sat, Feb 1, 2014 at 02:25:16AM +0100, Vik Fearing wrote:
>>> 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
On Sat, Feb 1, 2014 at 02:25:16AM +0100, Vik Fearing wrote:
> > 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
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 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 protoc
On Fri, Jan 31, 2014 at 04:38:21PM -0500, Tom Lane wrote:
> Bruce Momjian 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
>
Bruce Momjian 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 g
On Fri, Jan 31, 2014 at 06:34:27PM +0100, Vik Fearing wrote:
> >> Application code that relies on the values already has problems though
> >> since the returned values are pretty bogus now. Including the fact that
> >> it can return 0 as the number of modified rows which is checked for more
> >> fr
On 01/31/2014 06:19 PM, Bruce Momjian wrote:
> On Wed, Jul 24, 2013 at 08:08:32PM +0200, Andres Freund wrote:
>> On 2013-07-24 13:48:23 -0400, Tom Lane wrote:
>>> Vik Fearing writes:
Also worth mentioning is bug #7766.
http://www.postgresql.org/message-id/e1tlli5-0007tr...@wrigleys.postg
On Wed, Jul 24, 2013 at 08:08:32PM +0200, Andres Freund wrote:
> On 2013-07-24 13:48:23 -0400, Tom Lane wrote:
> > Vik Fearing writes:
> > > Also worth mentioning is bug #7766.
> > > http://www.postgresql.org/message-id/e1tlli5-0007tr...@wrigleys.postgresql.org
> >
> > Yeah, did you read that who
Andres Freund writes:
> I think fixing this for 9.4 is fine, but due to the compat issues I
> think it's to late for 9.3.
Agreed -- this is effectively a protocol change, albeit a pretty minor
one, so I can't see back-patching it.
regards, tom lane
--
Sent via pgsql-ha
On 2013-07-24 13:48:23 -0400, Tom Lane wrote:
> Vik Fearing writes:
> > Also worth mentioning is bug #7766.
> > http://www.postgresql.org/message-id/e1tlli5-0007tr...@wrigleys.postgresql.org
>
> Yeah, did you read that whole thread? The real issue here is going to
> be whether client-side code f
Vik Fearing writes:
> Also worth mentioning is bug #7766.
> http://www.postgresql.org/message-id/e1tlli5-0007tr...@wrigleys.postgresql.org
Yeah, did you read that whole thread? The real issue here is going to
be whether client-side code falls over on wider-than-32-bit counts.
We can fix the back
On 07/24/2013 04:04 PM, Vik Fearing wrote:
> On 07/22/2013 06:20 PM, Jeff Janes wrote:
>> On Fri, Jul 19, 2013 at 3:20 PM, Natalie Wenz
>> wrote:
>>> Hi all,
>>>
>>> I am moving some data from one table to another in 9.2.4, and keep seeing
>>> this strange scenario:
>>>
>>> insert into newtable
On 07/22/2013 06:20 PM, Jeff Janes wrote:
> On Fri, Jul 19, 2013 at 3:20 PM, Natalie Wenz wrote:
>> Hi all,
>>
>> I am moving some data from one table to another in 9.2.4, and keep seeing
>> this strange scenario:
>>
>> insert into newtable select data from oldtable where proc_date >= x and
>> p
15 matches
Mail list logo