Thanks, Thomas. It works for me now.
---------------------------------------- Jaanai Zhang Best regards! Thomas D'Silva <tdsi...@salesforce.com.invalid> 于2019年5月17日周五 上午3:24写道： > Jaanai, > > I added you to the JIRA administrators role, so you should be able to do > think now. Please let us know if it doesn't work. > > Thanks, > Thomas > > On Mon, May 13, 2019 at 6:22 PM Jaanai Zhang <cloud.pos...@gmail.com> > wrote: > > > Could you please help me add a 5.0.1 version > > > > > https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=58&projectKey=PHOENIX&view=planning.nodetail&versions=visible&epics=visible > > , > > it seems that I don't have the authority. Josh, Thomas > > ---------------------------------------- > > Jaanai Zhang > > Best regards! > > > > > > > > > > Josh Elser <els...@apache.org> 于2019年5月13日周一 下午10:54写道： > > > > > How did you identify the below issues? > > > > > > As I said in the other thread, I think we should move to the latest, > > > working HBase release for a 5.0.1 (which is 2.0.3 AFAIK). > > > > > > On 5/13/19 9:07 AM, Jaanai Zhang wrote: > > > > Hi, folks > > > > We decided to release a 5.0.1 that is discussed in the thread[1] and > > > > thread[2]. > > > > > > > > Since there is a lot of work to make Phoenix compatible with the > newer > > > > HBase 2.0.x(especially contains HBASE-21401), > > > > we try to fix HBase compat in a 5.1.0 version. In 5.0.1 we might > keep > > > the > > > > current HBase version? Josh, Thomas > > > > > > > > Right now I find the following issues, Is there anything else that > > needs > > > > to add to this release? > > > > > > > > *Bug* > > > > > > > > <https://issues.apache.org/jira/browse/PHOENIX-5266> > > > > > > > > PHOENIX-5266 <https://issues.apache.org/jira/browse/PHOENIX-5266> > > Client > > > > can only write on Index Table and skip data table if failure happens > > > > because of region split/move etc > > > > > > > > PHOENIX-5132 <https://issues.apache.org/jira/browse/PHOENIX-5132> > View > > > > indexes with different owners but of the same base table can be > > assigned > > > > same ViewIndexId > > > > > > > > PHOENIX-5138 <https://issues.apache.org/jira/browse/PHOENIX-5138> > > > ViewIndexId > > > > sequences created after PHOENIX-5132 shouldn't collide with ones > > created > > > > before it > > > > > > > > PHOENIX-4759 <https://issues.apache.org/jira/browse/PHOENIX-4759> > > During > > > > restart RS that hosts SYSTEM.CATALOG table may get stuck > > > > > > > > PHOENIX-5055 <https://issues.apache.org/jira/browse/PHOENIX-5055> > > Split > > > > mutations batches probably affects correctness of index data > > > > > > > > PHOENIX-5226 <https://issues.apache.org/jira/browse/PHOENIX-5226> > The > > > > format of VIEW_MODIFIED_PROPERTY_BYTES is incorrect as a tag of the > > cell > > > > > > > > PHOENIX-5018 <https://issues.apache.org/jira/browse/PHOENIX-5018> > > Index > > > > mutations created by UPSERT SELECT will have wrong timestamps > > > > > > > > PHOENIX-5019 <https://issues.apache.org/jira/browse/PHOENIX-5019> > > Index > > > > mutations created by synchronous index builds will have wrong > > timestamps > > > > > > > > PHOENIX-5169 <https://issues.apache.org/jira/browse/PHOENIX-5169> > > Query > > > > logger is still initialized for each query when the log level is off > > > > > > > > PHOENIX-5188 <https://issues.apache.org/jira/browse/PHOENIX-5188> > > > > IndexedKeyValue > > > > should populate KeyValue fields > > > > > > > > PHOENIX-5094 <https://issues.apache.org/jira/browse/PHOENIX-5094> > > Index > > > > can transition from INACTIVE to ACTIVE via Phoenix Client > > > > > > > > PHOENIX-5217 <https://issues.apache.org/jira/browse/PHOENIX-5217> > > > Incorrect > > > > result for COUNT DISTINCT limit > > > > > > > > PHOENIX-5184 <https://issues.apache.org/jira/browse/PHOENIX-5184> > > HBase > > > and > > > > Phoenix connection leaks in Indexing code path, OrphanViewTool and > > > > PhoenixConfigurationUtil > > > > > > > > PHOENIX-5207 <https://issues.apache.org/jira/browse/PHOENIX-5207> > > > Create > > > > index if not exists fails incorrectly if table has > 'maxIndexesPerTable' > > > > indexes already > > > > > > > > PHOENIX-5126 <https://issues.apache.org/jira/browse/PHOENIX-5126> > > > RegionScanner > > > > leak leading to store files not getting cleared > > > > > > > > PHOENIX-5122 <https://issues.apache.org/jira/browse/PHOENIX-5122> > > > PHOENIX-4322 > > > > breaks client backward compatibility > > > > > > > > PHOENIX-5101 <https://issues.apache.org/jira/browse/PHOENIX-5101> > > > > ScanningResultIterator > > > > getScanMetrics throws NPE > > > > > > > > > > > > > > > > > > > > *Improvement* > > > > > > > > PHOENIX-5213 <https://issues.apache.org/jira/browse/PHOENIX-5213> > > > > Phoenix-client > > > > improvements: add more relocations, exclude log binding, add source > jar > > > > > > > > PHOENIX-5048 <https://issues.apache.org/jira/browse/PHOENIX-5048> > > Index > > > > Rebuilder does not handle INDEX_STATE timestamp check for all index > > > > > > > > PHOENIX-4907 <https://issues.apache.org/jira/browse/PHOENIX-4907> > > > > IndexScrutinyTool > > > > should use empty catalog instead of null > > > > > > > > PHOENIX-5131 <https://issues.apache.org/jira/browse/PHOENIX-5131> > Make > > > > spilling to disk for order/group by configurable > > > > > > > > PHOENIX-5069 <https://issues.apache.org/jira/browse/PHOENIX-5069> > Use > > > > asynchronous refresh to provide non-blocking Phoenix Stats Client > Cache > > > > > > > > PHOENIX-4900 <https://issues.apache.org/jira/browse/PHOENIX-4900> > > Modify > > > > MAX_MUTATION_SIZE_EXCEEDED and MAX_MUTATION_SIZE_BYTES_EXCEEDED > > exception > > > > message to recommend turning autocommit on for deletes > > > > > > > > [1] > > > > > > > > > > https://lists.apache.org/thread.html/99fcc737d7a8f82ddffb1b34a64f7099f7909900b8bea36dd6afca16@%3Cdev.phoenix.apache.org%3E > > > > [2] > > > > > > > > > > https://lists.apache.org/thread.html/f9d9965b76335f64695ac403e84dda01a2b8425a8eedc30e4a805d54@%3Cdev.phoenix.apache.org%3E > > > > ---------------------------------------- > > > > Jaanai Zhang > > > > Best regards! > > > > > > > > > >
