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-ge
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
I had just started to wonder if it was something that when you responded. I
checked, and every case that I had where the numbers were wonky checked out
when I subtracted 2^32. Whew!
Thanks, Jeff!
On Jul 22, 2013, at 11:20 AM, Jeff Janes wrote:
> On Fri, Jul 19, 2013 at 3:20 PM, Natalie Wen
So, in an attempt to see if it was a fluke, I picked one of the date ranges I
was getting a different count for, and deleted the records, and then ran the
insert again. Interestingly, the delete result matched the insert result (which
was the same the second time as it was the first). I'll run a
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
> proc_date < y;
>
> INSERT 0 78551642
>
> select coun
No triggers, no rules. It's just a very boring, vanilla table. I have had
plenty of cases where the inserts fail because many of the data types are
different in the new table, and there is some junk that fails the cast. And
even though the insert result seems to indicate that it only inserted so
Natalie Wenz writes:
> I am moving some data from one table to another in 9.2.4, and keep seeing
> this strange scenario:
> ...
> So, my counts from the old and new tables match, but the result returned from
> the insert statement is sometimes a completely different number. (But not
> always.)
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
proc_date < y;
INSERT 0 78551642
select count(*) from newtable where proc_date >= x and proc_date < y;
count
-
21 matches
Mail list logo
