Question

I have a table called ticket, and it has a field called number and a foreign key called client that needs to work much like an auto-field (incrementing by 1 for each new record), except that the client chain needs to be able specify the starting number. This isn’t a unique field because multiple clients will undoubtedly use the same numbers (e.g. start at 1001). In my application I’m fetching the row with the highest number, and using that number + 1 to make the next record’s number. This all takes place inside of a single transaction (the fetching and the saving of the new record). Is it true that I won’t have to worry about a ticket ever getting an incorrect (duplicate) number under a high load situation, or will the transaction protect from that possibility? (note: I’m using PostgreSQL 9.x)

Answer 1

without locking the whole table on every insert/update, no. The way transactions work on PostgreSQL means that new rows that appear as a result of concurrent transactions never conflict with each other; and thats exactly what would be happening.

You need to make sure that updates actually cause the same rows to conflict. You would basically need to implement something similar to the mechanic used by PostgreSQL’s native sequences.

What I would do is add another column to the table referenced by your client column to represent the last_val of the sequence’s you’ll be using. So each transaction would look sort of like this:

BEGIN;

SET TRANSACTION SERIALIZABLE;

UPDATE clients 
  SET footable_last_val = footable_last_val + 1 
  WHERE clients.id = :client_id;

INSERT INTO footable(somecol, client_id, number) 
  VALUES (:somevalue, 
          :client_id, 
          (SELECT footable_last_val 
             FROM clients 
             WHERE clients.id = :client_id));

COMMIT;

So that the first update into the clients table fails due to a version conflict before reaching the insert.