Are increments with Postgres triggers atomic and high concurrency safe? - postgresql

Question

Given the following setup:
CREATE EXTENSION IF NOT EXISTS "pgcrypto";
CREATE TABLE IF NOT EXISTS foo (
id TEXT DEFAULT gen_random_uuid () NOT NULL,
text TEXT NOT NULL,
is_latest BOOLEAN DEFAULT TRUE,
version INTEGER NOT NULL DEFAULT 0,
updated_at TIMESTAMPTZ NOT NULL DEFAULT NOW(),
created_at TIMESTAMPTZ NOT NULL DEFAULT NOW()
);
CREATE UNIQUE INDEX foo_id_idx ON foo (id, is_latest);
CREATE INDEX foo_updated_at_idx ON foo (updated_at);
CREATE INDEX foo_created_at_idx ON foo (created_at);
CREATE OR REPLACE FUNCTION foo_copy_row ()
RETURNS TRIGGER
AS $BODY$
BEGIN
NEW.version = OLD.version + 1;
NEW.is_latest = TRUE;
NEW.updated_at = NOW();
NEW.created_at = OLD.created_at;
INSERT INTO foo (id, text, is_latest, version, updated_at, created_at)
VALUES (OLD.id, OLD.text, NULL, OLD.version, OLD.updated_at, OLD.created_at);
RETURN NEW;
END;
$BODY$
LANGUAGE plpgsql;
CREATE TRIGGER COPY BEFORE
UPDATE
ON foo FOR EACH ROW EXECUTE PROCEDURE foo_copy_row ();
I am able to successfully version my data, and on every update atomically increment the version column.
My problem is that when I have high concurrency updates on the same row I am expecting ORDER BY id, version DESC and ORDER BY id, updated_at DESC to be identical but they are not.
This is how I update my rows:
INSERT INTO foo (text) VALUES ('hello')
RETURNING *;
UPDATE foo SET text = 'welcome'
WHERE id = 'some-uuid' AND is_latest = TRUE
RETURNING *;
And this is an example of result:
SELECT id, is_latest, version, updated_at, created_at FROM foo ORDER BY id, updated_at DESC;
-
id | is_latest | version | updated_at | created_at
-------------------------------------+-----------+---------+-------------------------------+-------------------------------
4d2339ba-eb1f-4925-a4bc-753f2994bd5f | t | 4 | 2018-07-22 16:12:55.702035+00 | 2018-07-22 16:12:55.694725+00
4d2339ba-eb1f-4925-a4bc-753f2994bd5f | | 2 | 2018-07-22 16:12:55.698144+00 | 2018-07-22 16:12:55.694725+00
4d2339ba-eb1f-4925-a4bc-753f2994bd5f | | 1 | 2018-07-22 16:12:55.697429+00 | 2018-07-22 16:12:55.694725+00
4d2339ba-eb1f-4925-a4bc-753f2994bd5f | | 3 | 2018-07-22 16:12:55.697157+00 | 2018-07-22 16:12:55.694725+00
4d2339ba-eb1f-4925-a4bc-753f2994bd5f | | 0 | 2018-07-22 16:12:55.694725+00 | 2018-07-22 16:12:55.694725+00
What's the missing piece?
Is the trigger part of the transaction and is the UPDATE lock retained until both BEFORE and AFTER are executed?
Is it possible to end up with two rows with same id and version number?

Answer 1

That is not surprising. now() returns the time when the transaction started. There is no guarantee that the transaction that starts first will be the first one to perform the trigger.
Use the version to determine the order of the updates.