phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Taylor (JIRA)" <>
Subject [jira] [Commented] (PHOENIX-4382) Upsert of some big values not correct for immutable tables
Date Tue, 19 Dec 2017 21:11:00 GMT


James Taylor commented on PHOENIX-4382:

[~vincentpoon] - thanks for following up on this one. I'd like to understand how serious the
problem is:
- Will the problem potentially occur for a schema when a variable length field is followed
by a fixed length field like: VARCHAR + BIGINT?
- In the old scheme, do we only write the separator byte for a variable length column or do
we write a separator byte after fixed length columns too? Or are we only writing a separator
byte when the column is null?
- I remember we tried to optimize storage by not writing a zero byte for every contiguous
field that was null. Do we do this even if there's a single null column (i.e. writing a zero
byte plus another byte)?
- It looks like your fix needs to be rolled out in a minor release since if only the client-side
was rolled out, the server wouldn't read the new serialized format correctly. Is that correct?

I think it'd be good to update the description and subject to better capture the extent of
the problem and when it might occur. I also think we should do a 4.14 as soon as this gets
reviewed by [~tdsilva] and committed.

> Upsert of some big values not correct for immutable tables
> ----------------------------------------------------------
>                 Key: PHOENIX-4382
>                 URL:
>             Project: Phoenix
>          Issue Type: Bug
>    Affects Versions: 4.14.0
>            Reporter: Vincent Poon
>            Assignee: Vincent Poon
>         Attachments: PHOENIX-4382.v1.master.patch, PHOENIX-4382.v2.master.patch,
> For immutable tables, upsert of some values like Short.MAX_VALUE results in a null value
in query resultsets.  Mutable tables are not affected.  I tried with BigInt and got the same
> For Short, the breaking point seems to be 32512.  Numbers smaller than that are fine
(until you get closer to Short.MIN_VALUE...)
> See attached test - testShort() , testBigInt()

This message was sent by Atlassian JIRA

View raw message