Fix lock strategy

[juliangruber]

Process ids maybe be reused, UUIDs provider strong uniqueness guarantees.

[bajtos]

Looks mostly good, see one suggestion below.

Have you considered the migration path?

• What if there are some locked rows left over from the previous deployment, will your migration script handle that?
• Is there anything else to consider?

[bajtos]

Have you considered the migration path?

Do you have an idea how long it will take PG to rework those two columns for all the rows in the table now? I don't know how many there are. If there are fewer than 100k, we should be fine. If there are more than 100m, we are definitely in trouble.

[juliangruber]

What if there are some locked rows left over from the previous deployment, will your migration script handle that?

Numbers can be converted to Strings, this should be fine.

Do you have an idea how long it will take PG to rework those two columns for all the rows in the table now? I don't know how many there are. If there are fewer than 100k, we should be fine. If there are more than 100m, we are definitely in trouble.

I don't really see an alternative. We can delay publishing this as the queue is still being processed.

postgres=# select count(*) from measurements where locked_by_pid is not null;
  count
---------
 1100000