Mats Kindahl

> Let's not merge this before we are sure there are no performance regressions, since we're presenting performance numbers for `2.7.0` and we wouldn't want to risk invalidating them this...

Fails here as well https://github.com/timescale/timescaledb/runs/6827486034?check_suite_focus=true

Fails here as well: https://github.com/timescale/timescaledb/runs/7129308963?check_suite_focus=true

Fails [here](https://github.com/timescale/timescaledb/runs/8185103046?check_suite_focus=true) as well, but the error is "relation "disttable" does not exist" on line 27 (`VACUUM disttable`).

This patch solves the issue with tuples concurrently updated, but there remains a bug where two identical rows with the same job_id are added, which causes the scheduler to exit....

> Thanks for working on this bug and finding a solution! I understand that the current approach does not entirely solve the underlying issue but that it should already provide...

Fails here as well: https://github.com/timescale/timescaledb/runs/6591594389?check_suite_focus=true

And here: https://github.com/timescale/timescaledb/runs/6827486034?check_suite_focus=true ``` diff -u /home/runner/work/timescaledb/timescaledb/tsl/test/expected/dist_api_calls.out /home/runner/work/timescaledb/timescaledb/build/tsl/test/results/dist_api_calls.out --- /home/runner/work/timescaledb/timescaledb/tsl/test/expected/dist_api_calls.out 2022-06-10 08:25:58.171757882 +0000 +++ /home/runner/work/timescaledb/timescaledb/build/tsl/test/results/dist_api_calls.out 2022-06-10 08:29:52.126006906 +0000 @@ -380,13 +380,4 @@ (1 row) ANALYZE disttable_repl; -SELECT approximate_row_count('disttable_repl'); - approximate_row_count...

https://github.com/timescale/timescaledb/runs/7210303471?check_suite_focus=true

https://github.com/timescale/timescaledb/runs/7253018386?check_suite_focus=true