[YSQL] Columns with default values may be initialized to null instead #2021
Description
In YB 1.3.1.0, on Debian, it looks like columns with a default value of NOW() may, occasionally, be initialized to NULL instead. With a schema like
CREATE TABLE foo (
k TIMESTAMP DEFAULT NOW(),
v INT
) IF NOT EXISTS;
And a workload comprised of inserts (INSERT INTO foo (v) VALUES (?)), and reads (SELECT k, v FROM foo ORDER BY k), it appears that sometimes, k may wind up NULL, rather than being a timestamp. This log line shows a series of [k, v] pairs from a read; notice that it contains one row (13) with a timestamp, and one row (9) with null. 20190812T154729.000-0400.zip
2019-08-12 15:50:01,257{GMT} INFO [jepsen worker 5] yugabyte.ysql.append-table: table append11 has ([#inst "2019-08-12T19:49:57.609143000-00:00" 13] [nil 9])
Other tables may contain no null entries, or many nulls. These null values appear stable over multiple seconds. To reproduce, try Jepsen e324b33, and run
lein run test --os debian --version 1.3.1.0 -w ysql/append-table --concurrency 2n --time-limit 300
The checker doesn't verify this property, so the test failing or succeeding isn't meaningful. Instead, grep the logs for a line with a table with nil entries.
grep -e 'table append.\+ has.\+nil' store/latest/jepsen.log