workload/schemachange: "fix" workload

[ajwerner]

This is a variety of commits which fixes bugs in the schemachange workload. It also disables a number of features.

[cockroach-teamcity]

This change is 

[ajwerner]

I spun this up under stress on 256 cores: 7290 runs so far, 0 failures, over 20m0s. I feel reasonably good about it given some of the things it turned up extremely quickly when they existed. There's more features to turn back on but this is a good start.

[ajwerner]

@fqazi I have a feeling this may interest you. Might be worth stepping back and reading the code for this thing. It's powerful and finds bugs but could surely be more usable and extensible.

[fqazi]

Reviewed 6 of 9 files at r1.
Reviewable status: complete! 0 of 0 LGTMs obtained (waiting on @arulajmani and @postamar)

[arulajmani]

Reviewed 7 of 9 files at r1.
Reviewable status: complete! 0 of 0 LGTMs obtained (waiting on @ajwerner and @postamar)

---

pkg/workload/schemachange/operation_generator.go, line 207 at r1 (raw file):

	setColumnNotNull:        1,
	setColumnType:           1,
	insertRow:               0,

Disallowing inserts will inhibit our ability to test ALTER TYPE ... DROP VALUE right? Ideally we'd want to seed tables that use user defined types with some data.

Is the complication here mostly around computed columns overflowing (like you mention in a comment somewhere below)? If so, would it make sense to block inserts if the table contains computed columns further down instead? I'm not sure if this is even feasible, as I couldn't find with what probability we generate computed columns, and maybe thats crippling in itself.

---

pkg/workload/schemachange/operation_generator.go, line 796 at r1 (raw file):

			// Filter out the generated virtual columns.
			// TODO(ajwerner): Remove this after #61768 is fixed.

Looks like the issue linked is closed, so you could get rid of this thing.

---

pkg/workload/schemachange/operation_generator.go, line 1733 at r1 (raw file):

	rows := [][]string{}
	for _, col := range cols {
		if col.generated {

nit: you could get rid of this as this is always false here.

[ajwerner]

TFTR!

bors r=arulajmani

Reviewable status: complete! 0 of 0 LGTMs obtained (waiting on @arulajmani, @fqazi, and @postamar)

---

pkg/workload/schemachange/operation_generator.go, line 207 at r1 (raw file):

Previously, arulajmani (Arul Ajmani) wrote…

Disallowing inserts will inhibit our ability to test ALTER TYPE ... DROP VALUE right? Ideally we'd want to seed tables that use user defined types with some data.

Is the complication here mostly around computed columns overflowing (like you mention in a comment somewhere below)? If so, would it make sense to block inserts if the table contains computed columns further down instead? I'm not sure if this is even feasible, as I couldn't find with what probability we generate computed columns, and maybe thats crippling in itself.

We'll need to fix this. IIRC there were a few different issues. I wanted to stabilize this test before going back to features as this PR wasn't tiny as it is. The computed column overflow was the first one I was hitting.

Insert row also has the problem that there are combinations of schema changes which can fail permanently, generally involving drop column. I think we'll need to add a rule that says that we don't do drop column in a transaction that has schema changes which might fail. D

---

pkg/workload/schemachange/operation_generator.go, line 796 at r1 (raw file):

Previously, arulajmani (Arul Ajmani) wrote…

Looks like the issue linked is closed, so you could get rid of this thing.

Done.

---

pkg/workload/schemachange/operation_generator.go, line 1733 at r1 (raw file):

Previously, arulajmani (Arul Ajmani) wrote…

nit: you could get rid of this as this is always false here.

Done.

[craig]

Build succeeded:

• GitHub CI (Cockroach)