Hi Viraj, Would be better to include the changes in 5.1.4 as in any way it will take at least 3-4 days to complete the omid release.
Thanks, Rajeshbabu. On Thu, Jan 4, 2024 at 5:06 AM Viraj Jasani <vjas...@apache.org> wrote: > Thank you Kadir and Geoffrey for your replies!! > > > How does this affect 5.1.4, which is also listed as a Fix Version for > > PHOENIX-7106? > > Yes, it also needs to be ported to 5.1. Once the master PR is up for final > review, I would start working on the backport PR. > We just need some more additional testing to ensure old client (e.g. 5.1.3) > is compatible with the new server with the changes. > > Hence, yes it is now a blocker for upcoming 5.1.4 as well since 5.1.4 RC > preparation is still pending (while Omid release is in progress). > Otherwise if 5.1.4 was ready for release, I would have proposed immediate > 5.1.5 release to include the changes proposed with PHOENIX-7106. > > > On Wed, Jan 3, 2024 at 3:08 PM Geoffrey Jacoby <gjac...@apache.org> wrote: > > > I agree that data integrity issues are a higher priority than feature > > development, so I also support the decision. The fact that several of the > > major remaining 5.2 features are currently being developed in > long-running > > feature branches also helps, as work can continue there at the cost of a > > rebase later. > > > > How does this affect 5.1.4, which is also listed as a Fix Version for > > PHOENIX-7106? From the bug description it also sounds like 5.1.3 and the > > forthcoming .4 are affected, since we have server-side paging in 5.1. > (Feel > > free to move that to a separate thread if you feel it should be a > separate > > discussion.) Should this be a blocker for releasing 5.1.4? > > > > Geoffrey > > > > > > On Wed, Jan 3, 2024 at 5:06 PM Kadir Ozdemir < > > ka...@gsuite.cloud.apache.org> > > wrote: > > > > > Being a database, Phoenix has to make sure that the data stays on disk > > > intact and its queries return correct data. In this case, Phoenix fails > > to > > > return correct data for some queries if their scans experience region > > > movement. Now that we know these data integrity issues and how to > > reproduce > > > them, fixing them should be our first priority. So, I fully support > this > > > proposal. > > > > > > On Wed, Jan 3, 2024 at 10:58 PM Viraj Jasani <vjas...@apache.org> > wrote: > > > > > > > Hello, > > > > > > > > I would like to bring PHOENIX-7106 > > > > <https://issues.apache.org/jira/browse/PHOENIX-7106> to everyone's > > > > attention here and brief about the data integrity issues that we have > > in > > > > various coprocessors. Majority of the issues are related to the fact > > that > > > > we do not return valid rowkey for certain queries. If any region > moves > > in > > > > the middle of the scan, the HBase client relies on the last returned > > > rowkey > > > > and accordingly changes the scan boundaries while the scanner is > > getting > > > > reset to continue the scan operation. If the region does not move, > scan > > > is > > > > not expected to return invalid data, however if the region moves in > the > > > > middle of ongoing scan operation, scan would return invalid/incorrect > > > data > > > > causing data integrity issues. > > > > > > > > Given the critical nature of these issues, I would like to propose > that > > > we > > > > treat this as a high priority for the upcoming 5.2.0 release, and not > > > > include any other feature or big change to master branch until we > merge > > > > this. The PR is still not ready as additional changes are still in my > > > > local, requiring rebase with the current master. > > > > > > > > I would get back to this discuss thread as soon as the PR and the doc > > are > > > > updated with the latest findings so far. The changes include many of > > our > > > > coproc scanner implementations and hence it would require significant > > > > review as well. > > > > It would be great if we can hold on to merging any feature or big > > change > > > to > > > > master branch until this gets in so as to not complicate > > > merging/rebasing. > > > > Once this is merged to the master branch, I would like to cut 5.2 > > branch > > > > from master and we can move forward with 5.2.0 release. > > > > > > > > Please let me know if this looks good or if you have any other high > > > > priority work for 5.2.0. > > > > > > > > > >
