Tell us how to DROP USER!

Written by Written by Kaj Arnö Leave a comment on Tell us how to DROP USER!
DROP USER

Shortly, we will start coding a task, for which we would appreciate your input: How would you like to DROP USER?

Why do we ask?

DROP user (originating in MySQL in 2004) always used to just drop the account from the privilege tables, but left all existing connections active. You can argue that this was questionable in 2004, but it’s really unexpected and confusing in 2025, with MariaDB being ubiquitous as it is.

So now we’re considering changing it.

But changing a 20-year-old behavior cannot be done lightly. We want to ask
you, our users, what would you prefer DROP USER to do.

What are the options?

Are there several ways to DROP a USER, you might ask. Yes, there are!

We face a couple of options – tick off your favourite:

  1. Keep the old behaviour, for old times sake. But it would keep putting off all new MariaDB users coming from other databases.
  2. DROP USER should terminate all existing connections.
  3. DROP USER should wait until all existing connections terminate. This is what MariaDB usually does in similar situations, for example, DROP TABLE will wait until the table is no longer used.
  4. Default to wait but optionally invoke terminate using the syntax DROP USER FORCE.
  5. On top of DROP USER FORCE, also add a flag value old_mode=OLD_DROP_USER whereby DROP USER will behave as in 1, so that existing applications would have time to migrate.

Call to Action: Vote on our poll!

So, what should we do? Terminate? Wait? It depends?

Please vote below. And if you have more detailed input, please comment in MDEV-35617 itself.

=

Thanks Tadas for alerting us!

Footnote: This is all debated and described in MDEV-35617 DROP USER should leave no active session for that user. The MDEV-35617 bug-or-feature is fresh, from December. It was raised because the current dogmatic behaviour may seem unthinking, mindless, and pedantic.

Indeed, Tadas Balaišis, the reporter of the MDEV, was taken by surprise:

DROP USER deletes specified user, while there is connected session of user deleted. After deletion user is still able to select or modify data in that session. Is that a bug or designed behavior? How can I prevent deleted user from further actions in that session?

Tadas Balaišis in MDEV-35617