Pt-osc / MariaDB 11.4 - triggers on new table where DEFINER was role1 - created with DEFINER as user (role1@%)

Polyglot Projects Percona Toolkit
1 
<user>@<server>:~$ pt-online-schema-change --version
pt-online-schema-change 3.6.0

Recently ran pt-osc to add an index on a table which has after update/insert/delete triggers, all with DEFINER=role1

After successfully completing, users complained that they couldn’t insert to this table:

pymysql.err.OperationalError: (1449, “The user specified as a definer (‘role1’@‘%’) does not exist”)

Which is correct - that user doesn’t exist.

Because we run in RDS, we don’t have SUPER access and can’t just recreate with DEFINER=role1, we have to do it with set role role1 and definer=current_role

I was able to re-create all these triggers by logging in as a privileged user and running:

set role role1 ; 
delimiter $$
CREATE OR REPLACE DEFINER=current_role .... AFTER UPDATE <trigger definition>
$$
CREATE OR REPLACE DEFINER=current_role .... AFTER DELETE <trigger definition>
$$
CREATE OR REPLACE DEFINER=current_role .... AFTER INSERT <trigger definition>
$$
delimiter ;

I don’t see this listed as a limitation or any documentation on how to manage this this issue, so I assume pt-osc isn’t aware of the concept that DEFINER can be a role in MariaDB.

2

@psumner

I see this error irrespective of pt-osc operations while running a normal DML as well.

mysql> SET ROLE app_admin;

mysql> SELECT CURRENT_ROLE(); 
+-----------------+
| CURRENT_ROLE()  |
+-----------------+
| `app_admin`@`%` |

mysql> UPDATE test.employees SET salary = 2222 WHERE name = 'test';
ERROR 1449 (HY000): The user specified as a definer ('CURRENT_ROLE'@'%') does not exist

With pt-osc as well, this is reproducible on tables with DEFINER=CURRENT_ROLE.

It works fine when using the exact definer name e.g, DEFINER = app_admin instead of the CURRENT_ROLE.

pt-online-schema-change \
  --alter "ADD INDEX (name)" \
  --user=root \
  --password="Root@1234" \
  --host=127.0.0.1 \
  --preserve-triggers \
  --port=3306 \
  D=test,t=employees \
  --execute

Altering new table...
Altered `test`.`_employees_new` OK.
2026-08-27T13:14:48 Creating triggers...
2026-08-27T13:14:48 Created triggers OK.
2026-08-27T13:14:48 Copying approximately 4 rows...
2026-08-27T13:14:48 Copied rows OK.
2026-08-27T13:14:48 Adding original triggers to new table.
2026-08-27T13:14:48 Analyzing new table...
2026-08-27T13:14:48 Swapping tables...
2026-08-27T13:14:48 Swapped original and new tables OK.
2026-08-27T13:14:48 Dropping old table...
2026-08-27T13:14:48 Dropped old table `test`.`_employees_old` OK.
2026-08-27T13:14:48 Dropping triggers...
2026-08-27T13:14:48 Dropped triggers OK.
Successfully altered `test`.`employees`.

mysql> INSERT INTO test.employees (name, salary) VALUES ('tt', 50000);
Query OK, 1 row affected (0.00 sec)

Are you sure that before the pt-osc operation, the DMLs are working properly on the same table without any such problems? Did you try any manual ones?

Can you please share the information below to match the role level details?

mysql> SELECT trigger_name, definer FROM information_schema.triggers WHERE TRIGGER_NAME = '<TRIGGER_NAME>';

mysql> SELECT CURRENT_ROLE();

mysql> SELECT user, host FROM mysql.user WHERE user = '<ROLE_NAME>';

mysql> SHOW GRANTS FOR '<ROLE_NAME>' @'<HOST>';