[postgressomethi]

Sequences kind of have the same issue, because you don't know if a gap is because of a rollback or an uncommitted transaction. Though with some logic you can do a pretty good job at this with sequences. And then you're not in the realm of "simple" anymore, at all.

[_acco]

Any ideas for a simple polling implementation that's more robust?

[farsa]

It's not exactly simple as it involves some postgres specific knowledge, but you can make it reliable when working with transaction ids (see https://event-driven.io/en/ordering_in_postgres_outbox/).

[qazxcvbnm]

I've had pretty much the exact same problem and what I went for in my low-volume case was to simply add advisory locks such that I can guarantee the transaction start times provide correct ordering.

[oconnore]

Set the trigger to add the primary key + change time to a separate table, then scan/truncate that table to poll changes.