sql, jobs: schema change jobs are erroneously queued for in-txn schema changes #45985
Description
In cockroach demo on 2863173:
root@127.0.0.1:56758/movr> begin;
Now adding input for a multi-line SQL transaction client-side (smart_prompt enabled).
Press Enter two times to send the SQL text collected so far to the server, or Ctrl+C to cancel.
You can also use \show to display the statements entered so far.
-> create table t (a int);
-> alter table t add column b int;
-> commit;
COMMIT
Time: 27.151ms
root@127.0.0.1:56758/movr> show jobs;
job_id | job_type | description | statement | user_name | status | running_status | created | started | finished | modified | fraction_completed | error | coordinator_id
---------------------+---------------+----------------------------------------------------------------------------------------------------------------------------+-----------+-----------+-----------+----------------+----------------------------------+----------------------------------+----------------------------------+----------------------------------+--------------------+-------+-----------------
536958125229670401 | SCHEMA CHANGE | ALTER TABLE movr.public.t ADD COLUMN b INT8 | | root | succeeded | NULL | 2020-03-11 14:30:15.362633+00:00 | 2020-03-11 14:30:15.377983+00:00 | 2020-03-11 14:30:15.384583+00:00 | 2020-03-11 14:30:15.383424+00:00 | 1 | | 1
<...other rows...>
We shouldn't be queuing a job for new tables where schema changes are run entirely in the transaction in which the table was created. This is happening because we're calling runSchemaChangesInTxn() in planner.writeTableDescToBatch() if the table is new, but we always indiscriminately queue a schema change job before that. The job doesn't do anything because the schema change was finished, but we should still fix this and write a regression test for it.