Re: TIMESTAMP and PgPL/SQL
От | Tom Lane |
---|---|
Тема | Re: TIMESTAMP and PgPL/SQL |
Дата | |
Msg-id | 752.1036441016@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | TIMESTAMP and PgPL/SQL (Kyle Burton <kburton@hmsonline.com>) |
Список | pgsql-general |
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
В списке pgsql-general по дате отправления: