Skip to:

  1. Skip to Jira Navigation
  2. Skip to Side Navigation
  3. Skip to Main Content

"START TRANSACTION READ ONLY" does not update session variable "tx_read_only"

Description

Session variable "@@tx_read_only" is not updated when starting a read only transaction using: "START TRANSACTION READ ONLY;"

The session variable "tx_read_only" is capable of controlling of controlling read_only, as the following tests show.

 

REQUEST: That session variable "tx_read_only" be updated when executing "START TRANSACTION READ ONLY;"

When safety checking transactions to ensure that they are read-only, this variable would be useful to read, rather than attempting an insert to verify if read_only is actually on.

I've attached a copy of my system variables for reference.

Environment

None

Attachments

1

Smart Checklist

Activity

Show:

Lalit Choudhary September 23, 2019 at 7:08 AM

Hi Alexander,

Upstream has the same behavior if you think it's a bug/need improvement in functionality. I would request you to create submit a report in Upstream MySQL. 

https://bugs.mysql.com/

Alexandre K September 20, 2019 at 3:56 PM

If "tx_read_only" isn't updated when executing "START TRANSACTION READ ONLY," how can we check if the transaction is in a read_only state?

Lalit Choudhary September 20, 2019 at 9:41 AM

Not a bug

Lalit Choudhary September 20, 2019 at 9:40 AM

Hello Alexander,

Thank you for the report.

Even if we update tx_read_only=ON along with  START TRANSACTION READ ONLY the result will be same.

and regarding checking transactions to ensure that they are read-only, the transaction started as read-only so I don't think we need any extra check if it's read-only. 

I see same behavior in upstream mysql, you create a bug with MySQL upstream if you want to recheck on this.

Example:

 

Even if we update tx_read_only=ON along with  START TRANSACTION READ ONLY the result will be same.

 

Not a Bug

Details

Assignee

Reporter

Labels

Affects versions

Priority

Smart Checklist

Created September 20, 2019 at 1:27 AM
Updated March 6, 2024 at 11:50 AM
Resolved September 20, 2019 at 9:41 AM