Kyle Burton <kburton@hmsonline.com> writes:
> Sequentialy inserted records will have a timestamp that varys
> independent of any system time - sometimes subsequent insetions will end
> up with a timestamp that is _before_ their preceeding records.
CURRENT_TIMESTAMP is defined to return the time of transaction start.
If you've got concurrent transactions inserting into the same table,
it's certainly possible that transaction A might start before
transaction B and then insert a record into the table after transaction
B does.
But it's not entirely clear to me how you're defining "before" here.
Physical ordering in the table is not a reliable guide.
In most situations, the only way to ensure that there's a
well-understood ordering between two concurrent transactions is for each
to successively acquire some exclusive lock before it does any useful
work. This is a recipe for poor concurrent performance, so if you find
yourself feeling you need that, it's a good idea to take two steps back
and ask yourself exactly why.
regards, tom lane