PostgreSQL: CURRENT_TIMESTAMP и CLOCK_TIMESTAMP Разрешение: Windows против Linux?

Question

Итак, у меня есть эта интересная проблема с функциями синхронизации PostgreSQL.

Вот ситуация. У нас есть предсерийный сервер (Linux), на котором мы размещаем наши приложения в разработке. Я также делаю некоторую работу над локальной копией этой БД (Windows) на случай, если с сервером происходит еще более важная работа. Недавно я столкнулся с проблемой, когда я начал получать нарушения первичного ключа в таблице журналов в моей локальной копии БД. Я думал, что это будет невозможно, так как я использовал CLOCK_TIMESTAMP (текущее системное время) в качестве первичного ключа. Кроме того, я тестировал на сервере pre-prod, и он работал нормально. Поэтому я провел некоторое расследование. В конце концов я обнаружил, что если я запускаю "SELECT CLOCK_TIMESTAMP()" на сервере, он возвращает время до микросекунды. Если я запускаю его на своем локальном хосте, он уменьшается до миллисекунды. Таким образом, проблема возникает, когда происходит более одного обновления, прежде чем таймер перейдет к следующей миллисекунде, что определенно возможно, учитывая некоторые из наших процессов.

Итак, мой вопрос заключается в следующем. Почему это происходит и как я могу это исправить? Это какая-то неясная обстановка, которую я пока не смог найти? Или это отличается в разрешениях таймера Windows против Linux?

Редактировать: то же самое происходит с CURRENT_TIMESTAMP, NOW() и всеми другими встроенными функциями, возвращающими временную метку.

Спасибо

Answer 1

Цитировать Тома Лейна в этой ветке pg_hackers:

http://www.postgresql.org/message-id/[e-mail]

Я полагаю, что вы действительно спрашиваете не о точности типа данных, а о точности чтения now(). Вам не повезло - Windows просто не выставляет вызов, чтобы увеличить время настенных часов до 1 мсек.

Имейте в виду, что то, что возвращает машина Linux, может быть в значительной степени фантазией и в младших битах.

Чтобы решить вашу проблему, рассмотрите возможность использования серийного номера в качестве первичного ключа. (Предполагая, конечно, что вам на самом деле нужен первичный ключ в первую очередь для файла журнала.)