Sequences, txids, and serial order of transactions

Hi,

we have a use case similar to auditing packages like pgMemento or Audit Trigger 91plus – we are looking to keep an ordered history of certain write transactions.  I'm trying to understand the trade-offs between different ways of getting that order, i.e., assigning numbers to transactions (ideally strictly monotonic, modulo concurrency).  All of our transactions are serializable (for now).

The two main candidates I'm aware of are txid_current() or nextval() of a sequence; but perhaps there are other mechanisms we should be considering.

Some observations and questions from my investigations so far (and please correct me if any of this is wrong):

(1) managing a counter in a table would essentially eliminate concurrency, so we're not too interested in that

(2) the orders produced by txid_current and a sequence can be different (unsurprisingly).  (If it was desirable to make them match, we could probably do so by briefly holding a lock while we call both txid_current and nextval – seems like this shouldn't limit concurrency too much.  Or would it?  Is one of them potentially slow?)

(3) logical replication has mechanisms to keeps sequences in sync, but not txid_current (unsurprisingly)

(4) behaviors like http://permalink.gmane.org/gmane.comp.db.postgresql.bugs/35636 make me think that monotonicity of txid_current is not something we should bet on

(5) Postgres can give us a "high watermark" ("no transactions with IDs below this number are still in-flight") for txid_current (using txid_snapshot_xmin(txid_current_snapshot())), but has no equivalent feature for sequences

(6) neither txid_current nor a sequence give us a valid serial order of the transactions

(7) given that we can't get a valid serial order, what guarantees can we get from the ordering?  I'm not entirely sure what to look for, but at a minimum, it seems like we want writes that clobber each other to be correctly ordered.  Are they, for both txid_current and for sequences?  My guess was "yes" for txids (seems intuitive but just a guess) and "no" for sequences (because https://www.postgresql.org/docs/current/static/functions-sequence.html mentions that sequences are non-transactional); but for sequences, I couldn't immediately construct a counterexample and am wondering whether that's by design.  Specifically, it seems that Postgres acquires the snapshot for the transaction (if it hasn't already) when I call nextval(), and as long as the snapshot is acquired before the sequence is incremented, I suspect that this guarantees ordering writes.  Does it?

(8) ...and is the snapshot acquired before or after the increment?  (Is it acquired as soon as Postgres sees SELECT, before even evaluating nextval()?  I think that's what I'm seeing.  Is that something we can rely on, or should we SELECT txid_current_snapshot() before SELECT nextval() to be on the safe side?)

(9) are there other important properties that one order satisfies but the other doesn't, or that neither satisfies but that we should be aware of?

(3) and (4) seem like strong reasons to go with a sequence, as long as we can live without (5) and figure out (7) and (8).

Any help appreciated,

Christian.