PostgreSQL: CURRENT_TIMESTAMP AND CLOCK_TIMESTAMP Resolution: Windows vs. Linux?

Question

So I have this interesting problem with the PostgreSQL timing functions.

Here's the situation. We have a pre-production server (Linux) that we house our in-development applications. I also do some work on a local copy of that DB (Windows) in case there is some more important work going on with the server. I recently ran into an issue where I started to get primary key violations on a logging table on my local DB copy. I thought this would be impossible since I was using the CLOCK_TIMESTAMP (current system time) as the primary key. In addition, I tested on the pre-prod server and it worked fine. So I did some investigating. I eventually found out that if I run 'SELECT CLOCK_TIMESTAMP()' on the server, it returns the time down to the microsecond. If I run it on my localhost, it only goes down to the millisecond. So the issue occurs when more than one update occurs before the timer gets to the next millisecond, which is definitely possible given some of our processes.

So my question is this. Why is this happening and how can I fix it? Is this some obscure setting I haven't been able to find yet? Or is it a different in the timer resolutions of Windows vs Linux?

Edit: The same thing happens with CURRENT_TIMESTAMP, NOW(), and all other timestamp-returning built-in functions.

Thanks

Answer 1

Quoting Tom Lane on this pg_hackers thread:

http://www.postgresql.org/message-id/9699.1262011789@sss.pgh.pa.us

I suppose what you're really asking about is not the precision of the datatype but the precision of now() readings. You're out of luck --- Windows just doesn't expose a call to get the wall clock time to better than 1 msec.

Keep in mind that whatever the Linux machine is returning might be largely fantasy in the low-order bits, too.

To sort out your problem, consider using a serial as the primary key. (Assuming, of course, that you actually need a primary key in the first place for the log file.)