Skip to content

Conversation

patrickbirch
Copy link
Collaborator

…gin_lock_status table

Copy link
Collaborator

@dlenev dlenev left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hello Patrick!

I have one suggestion about the proposed documentation change. Please see below.
Otherwise it looks fine to me!

| `IS_TRACKING_ACTIVE` | `enum('YES','NO')` | Indicates whether failed login tracking is enabled for the account |
| `MAX_ATTEMPTS` | `INTEGER` | Maximum number of failed login attempts allowed before account is locked (corresponds to FAILED_LOGIN_ATTEMPTS clause value in CREATE USER statement) |
| `PASSWORD_LOCK_DAYS` | `INTEGER` | Number of days for which account will be temporarily locked after exceeding the MAX_ATTEMPS limit. Set to -1 if account is locked forever (corresponds to PASSWORD_LOCK_TIME clause value in CREATE USER) |
| `IS_LOCKED` | `BOOLEAN` | Indicates if account is temporarily locked by failed login lock tracking. NULL if tracking is not enabled for account |
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it is worth emphasizing that the contents of this field has no relation to account locking not related to failed login attempt tracking. E.g. by adding something like: "Please note that if the account is locked using CREATE USER or ALTER TABLE statements with ACCOUNT LOCK clause, and not due to failed login lock tracking, this fact won't be reflected in this column. One should look at account_locked column in mysql.users table to see this instead".
What do you think?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants