# \--where clause incorrectly applied to child tables in pt-online-schema-change (causes “unknown column” error)

**URL:** <https://forums.percona.com/t/where-clause-incorrectly-applied-to-child-tables-in-pt-online-schema-change-causes-unknown-column-error/39442>\
**Category:** Percona Toolkit\
**Created:** [September 23, 2025, 8:47am UTC](https://forums.percona.com/t/where-clause-incorrectly-applied-to-child-tables-in-pt-online-schema-change-causes-unknown-column-error/39442 "2025-09-23T08:47:59Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![rukbat](https://avatars.discourse-cdn.com/v4/letter/r/73ab20/32.png) [@rukbat](https://forums.percona.com/u/rukbat)\
**Post date:** [September 23, 2025, 8:47am UTC](https://forums.percona.com/t/where-clause-incorrectly-applied-to-child-tables-in-pt-online-schema-change-causes-unknown-column-error/39442/1 "2025-09-23T08:47:59Z")

</div>

Hello,

when using pt-online-schema-change with the --where option on a table that has foreign-key child tables, the tool crashes during the row-estimate phase for each child.

Steps to reproduce:

```auto
Create two tables with a foreign-key relationship, e.g.:

CREATE TABLE parent (
    id INT PRIMARY KEY,
    status VARCHAR(10)
);

CREATE TABLE child (
    id INT PRIMARY KEY,
    parent_id INT,
    FOREIGN KEY (parent_id) REFERENCES parent(id)
);

```

Populate both tables with sample data.

Run:

> pt-online-schema-change  
> –execute  
> –force  
> –alter-foreign-keys-method auto  
> –alter “ENGINE=InnoDB”  
> –where “status = ‘active’”  
> D=dbname,t=parent

Observe the failure with an error similar to:

> # NibbleIterator:6302 10847 EXPLAIN SELECT \* FROM `dbname`.`child` WHERE status = ‘active’
> 
> DBD::mysql::db selectrow\_hashref failed: fetch() without execute() [for Statement “EXPLAIN SELECT \* FROM `dbname`.`child` WHERE status = ‘active’”] at /opt/percona-toolkit-3.7.0-2/bin/pt-online-schema-change line 6303.

Because the WHERE expression references columns that exist only in the parent table, MySQL returns `ERROR 1054 (42S22): Unknown column ‘’ in ‘where clause’`. This aborts the migration even though the parent table itself would process fine.

It looks like a bug, but I’m unable to open a ticket because Jira appears to be experiencing an issue and won’t let me create a new ticket (ref: [https://status.atlassian.com/](https://status.atlassian.com/)).

---

<div class="post-metadata">

**Author:** ![Vinodh\_Krishnaswamy](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/vinodh_krishnaswamy/32/46_2.png) [@Vinodh\_Krishnaswamy](https://forums.percona.com/u/Vinodh_Krishnaswamy)\
**Post date:** [September 24, 2025, 6:47pm UTC](https://forums.percona.com/t/where-clause-incorrectly-applied-to-child-tables-in-pt-online-schema-change-causes-unknown-column-error/39442/2 "2025-09-24T18:47:33Z")

</div>

Hi @rukbat ,

Welcome to the community!

> [@rukbat](#):
>
> Because the WHERE expression references columns that exist only in the parent table, MySQL returns `ERROR 1054 (42S22): Unknown column ‘’ in ‘where clause’`. This aborts the migration even though the parent table itself would process fine.

While your test proves the same (and I could repeat the same), why do you want to use “_–where”_ option in this case? As per the documentation, it is not advised to use as it may cause data loss.

> **[Percona Toolkit Documentation](https://docs.percona.com/percona-toolkit/pt-online-schema-change.html#cmdoption-pt-online-schema-change-where)**
>
> Command-line tools for common MySQL database administration tasks.

> Warning! If used without options `--no-drop-new-table` and `--no-swap-tables` may lead to data loss, therefore this operation only allowed if option [`--force`](https://docs.percona.com/percona-toolkit/pt-online-schema-change.html#cmdoption-pt-online-schema-change-force) also specified.

I tested with those options and could repeat the same issue:

```auto
$ pt-online-schema-change --dry-run --alter-foreign-keys-method auto --alter "ENGINE=InnoDB" --where "status='active'" --no-drop-new-table --no-swap-tables D=vinodh,t=parent,h=127.0.0.1,P=8041,u=msandbox,p=msandbox
Operation, tries, wait:
  analyze_table, 10, 1
  copy_rows, 10, 0.25
  create_triggers, 10, 1
  drop_triggers, 10, 1
  swap_tables, 10, 1
  update_foreign_keys, 10, 1
DBD::mysql::db selectrow_hashref failed: Unknown column 'status' in 'where clause' [for Statement "EXPLAIN SELECT * FROM `vinodh`.`child` WHERE status='active'"] at /usr/bin/pt-online-schema-change line 6303.

```

At the same time, I have tested without –where and –force options, the tool works as expected:

```auto
$ pt-online-schema-change --dry-run --alter-foreign-keys-method auto --alter "ENGINE=InnoDB" D=vinodh,t=parent,h=127.0.0.1,P=8041,u=msandbox,p=msandbox --force
Operation, tries, wait:
  analyze_table, 10, 1
  copy_rows, 10, 0.25
  create_triggers, 10, 1
  drop_triggers, 10, 1
  swap_tables, 10, 1
  update_foreign_keys, 10, 1
Child tables:
  `vinodh`.`child` (approx. 10051 rows)
Will automatically choose the method to update foreign keys.
Starting a dry run. `vinodh`.`parent` will not be altered. Specify --execute instead of --dry-run to alter the table.
Creating new table...
Created new table vinodh._parent_new OK.
Altering new table...
Altered `vinodh`.`_parent_new` OK.
Not creating triggers because this is a dry run.
Not copying rows because this is a dry run.
Not determining the method to update foreign keys because this is a dry run.
Not updating foreign key constraints because this is a dry run.
Not swapping tables because this is a dry run.
Not dropping old table because this is a dry run.
Not dropping triggers because this is a dry run.
2025-09-24T17:20:46 Dropping new table...
2025-09-24T17:20:46 Dropped new table OK.
Dry run complete. `vinodh`.`parent` was not altered.

```

However, I have created a bug for the same as it is not the expected behaviour - [Jira](https://perconadev.atlassian.net/browse/PT-2481). Thanks for reporting to us.

Regards,

Vinodh Guruji