From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Kyle Burton <kburton(at)hmsonline(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: TIMESTAMP and PgPL/SQL |
Date: | 2002-11-04 20:16:56 |
Message-ID: | 752.1036441016@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Kyle Burton <kburton(at)hmsonline(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Mikheev, Vadim | 2002-11-04 20:23:23 | Re: [HACKERS] Database replication... - Mission Critica |
Previous Message | Kyle Burton | 2002-11-04 19:58:38 | TIMESTAMP and PgPL/SQL |