[DISCUSS] Time for 5.2.1 release
Hi, We have sufficient changes, improvements and fixes available on the 5.2 branch to start 5.2.1 release. A couple of improvements can still be included with the 5.2.1 release (e.g. bloom filter for multi-point lookups). I can start off with the release process by the end of next week unless there are any objections. Please let me know if you think any other important fixes or improvements are worth including in the release.
[jira] [Updated] (PHOENIX-6066) MetaDataEndpointImpl.doGetTable should acquire a readLock instead of an exclusive writeLock on the table header row
[ https://issues.apache.org/jira/browse/PHOENIX-6066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Yuan Jiang updated PHOENIX-6066: Fix Version/s: 5.2.1 5.3.0 > MetaDataEndpointImpl.doGetTable should acquire a readLock instead of an > exclusive writeLock on the table header row > --- > > Key: PHOENIX-6066 > URL: https://issues.apache.org/jira/browse/PHOENIX-6066 > Project: Phoenix > Issue Type: Improvement >Affects Versions: 5.0.0, 4.15.0 >Reporter: Chinmay Kulkarni >Assignee: Palash Chauhan >Priority: Major > Labels: quality-improvement > Fix For: 5.2.1, 5.3.0 > > > Throughout MetaDataEndpointImpl, wherever we need to acquire a row lock we > call > [MetaDataEndpointImpl.acquireLock|https://github.com/apache/phoenix/blob/bba7d59f81f2b91342fa5a7ee213170739573d6a/phoenix-core/src/main/java/org/apache/phoenix/coprocessor/MetaDataEndpointImpl.java#L2377-L2386] > which gets an exclusive writeLock on the specified row [by > default|https://github.com/apache/phoenix/blob/bba7d59f81f2b91342fa5a7ee213170739573d6a/phoenix-core/src/main/java/org/apache/phoenix/coprocessor/MetaDataEndpointImpl.java#L2378]. > Thus, even operations like doGetTable/getSchema/getFunctions which are not > modifying the row will acquire a writeLock on these metadata rows when a > readLock should be sufficient (see [doGetTable > locking|https://github.com/apache/phoenix/blob/bba7d59f81f2b91342fa5a7ee213170739573d6a/phoenix-core/src/main/java/org/apache/phoenix/coprocessor/MetaDataEndpointImpl.java#L2932] > as an example). The problem with this is, even a simple UPSERT/DELETE or > SELECT query triggers a doGetTable (if the schema is not cached) and can > potentially block other DDLs and more importantly other queries since these > queries will wait until they can get a rowLock for the table header row. Even > seemingly unrelated operations like a CREATE VIEW AS SELECT * FROM T can > block a SELECT/UPSERT/DELETE on table T since the create view code needs to > fetch the schema of the parent table. > Note that this is exacerbated in cases where we do server-server RPCs while > holding rowLocks for example > ([this|https://github.com/apache/phoenix/blob/1d844950bb4ec8221873ecd2b094c20f427cd984/phoenix-core/src/main/java/org/apache/phoenix/coprocessor/MetaDataEndpointImpl.java#L2459-L2461] > and > [this|https://github.com/apache/phoenix/blob/1d844950bb4ec8221873ecd2b094c20f427cd984/phoenix-core/src/main/java/org/apache/phoenix/coprocessor/MetaDataEndpointImpl.java#L2479-L2484]) > which is another issue altogether. > This Jira is to discuss the possibility of acquiring a readLock in these > "read metadata" paths to avoid blocking other "read metadata" requests > stemming from concurrent queries. The current behavior is potentially a perf > issue for clients that disable update-cache-frequency. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (PHOENIX-7348) Default INCLUDE scopes given in CREATE CDC are not getting recognized
[ https://issues.apache.org/jira/browse/PHOENIX-7348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Viraj Jasani resolved PHOENIX-7348. --- Resolution: Fixed > Default INCLUDE scopes given in CREATE CDC are not getting recognized > - > > Key: PHOENIX-7348 > URL: https://issues.apache.org/jira/browse/PHOENIX-7348 > Project: Phoenix > Issue Type: Bug >Reporter: Hari Krishna Dara >Assignee: Hari Krishna Dara >Priority: Minor > Fix For: 5.3.0 > > > The CREATE CDC statement allows specifying a default for the change image > scopes which should get used when there is no query hint, but this value is > not getting used. There is also no test to catch this issue. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (PHOENIX-7348) Default INCLUDE scopes given in CREATE CDC are not getting recognized
[ https://issues.apache.org/jira/browse/PHOENIX-7348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Viraj Jasani updated PHOENIX-7348: -- Fix Version/s: 5.3.0 > Default INCLUDE scopes given in CREATE CDC are not getting recognized > - > > Key: PHOENIX-7348 > URL: https://issues.apache.org/jira/browse/PHOENIX-7348 > Project: Phoenix > Issue Type: Bug >Reporter: Hari Krishna Dara >Assignee: Hari Krishna Dara >Priority: Minor > Fix For: 5.3.0 > > > The CREATE CDC statement allows specifying a default for the change image > scopes which should get used when there is no query hint, but this value is > not getting used. There is also no test to catch this issue. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (PHOENIX-6714) Return update status from Conditional Upserts
[
https://issues.apache.org/jira/browse/PHOENIX-6714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Viraj Jasani resolved PHOENIX-6714.
---
Resolution: Fixed
> Return update status from Conditional Upserts
> -
>
> Key: PHOENIX-6714
> URL: https://issues.apache.org/jira/browse/PHOENIX-6714
> Project: Phoenix
> Issue Type: Improvement
>Reporter: Tanuj Khurana
>Assignee: Jing Yu
>Priority: Major
> Fix For: 5.2.1, 5.3.0
>
>
> {code:java}
> 0: jdbc:phoenix:localhost> upsert into T1 values ('cd', 123);
> 1 row affected (0.005 seconds)
> 0: jdbc:phoenix:localhost> upsert into T1 values ('cd', 123) on duplicate key
> ignore;
> 1 row affected (0.008 seconds){code}
> Even when the row already exists, we return “1” row updated.
> {code:java}
> 0: jdbc:phoenix:localhost> upsert into T1 values ('cd', 123) on duplicate key
> update
> val=val;
> 1 row affected (0.01 seconds) {code}
> In this case, the value of column ‘val’ does not change so we could return
> “0“ to denote that fact. I mentioned ”could“ because as per the current
> implementation even though from the application perspective the value of the
> column is the same, from HBase perspective we are doing another PUT mutation
> which adds another version to the underlying cell and updates the cell
> timestamp. We also update the timestamp of the empty cell. So, technically
> this is an update from HBase perspective.
> Referring MYSQL which has similar conditional update constructs, its
> documentation says: “ With ON DUPLICATE KEY UPDATE, the affected-rows value
> per row is 1 if the row is inserted as a new row, 2 if an existing row is
> updated, and 0 if an existing row is set to its current values.”
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (PHOENIX-6714) Return update status from Conditional Upserts
[
https://issues.apache.org/jira/browse/PHOENIX-6714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Viraj Jasani updated PHOENIX-6714:
--
Fix Version/s: 5.2.1
5.3.0
> Return update status from Conditional Upserts
> -
>
> Key: PHOENIX-6714
> URL: https://issues.apache.org/jira/browse/PHOENIX-6714
> Project: Phoenix
> Issue Type: Improvement
>Reporter: Tanuj Khurana
>Assignee: Jing Yu
>Priority: Major
> Fix For: 5.2.1, 5.3.0
>
>
> {code:java}
> 0: jdbc:phoenix:localhost> upsert into T1 values ('cd', 123);
> 1 row affected (0.005 seconds)
> 0: jdbc:phoenix:localhost> upsert into T1 values ('cd', 123) on duplicate key
> ignore;
> 1 row affected (0.008 seconds){code}
> Even when the row already exists, we return “1” row updated.
> {code:java}
> 0: jdbc:phoenix:localhost> upsert into T1 values ('cd', 123) on duplicate key
> update
> val=val;
> 1 row affected (0.01 seconds) {code}
> In this case, the value of column ‘val’ does not change so we could return
> “0“ to denote that fact. I mentioned ”could“ because as per the current
> implementation even though from the application perspective the value of the
> column is the same, from HBase perspective we are doing another PUT mutation
> which adds another version to the underlying cell and updates the cell
> timestamp. We also update the timestamp of the empty cell. So, technically
> this is an update from HBase perspective.
> Referring MYSQL which has similar conditional update constructs, its
> documentation says: “ With ON DUPLICATE KEY UPDATE, the affected-rows value
> per row is 1 if the row is inserted as a new row, 2 if an existing row is
> updated, and 0 if an existing row is set to its current values.”
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
