Обсуждение: timestamp weirdness

We are having some strange behavior with PostgreSQL 7.1.3 where rows
are inserted with a timestamp that is out of order... here is the
table description and a few rows:


                             Table "event_page"
   Attribute   |           Type           |             Modifier
--------------+--------------------------+----------------------------------
  user_id      | oid                      |
  session_id   | character varying(24)    |
  course_ident | character varying(128)   |
  page         | character varying(32)    |
  date         | timestamp with time zone | default "timestamp"('now'::text)


  69714 |   61381 | yVLsSYYpZIa1G54VnDY7qcz2 | COG_001_ELEARNING |
15.html | 2002-01-31 18:07:21+08
  69715 |   61381 | yVLsSYYpZIa1G54VnDY7qcz2 | COG_001_ELEARNING |
16.html | 2002-01-31 18:07:40+08
  69717 |   61453 | uZuNbGXsWnXXRECH6PGeFdtf | COG_001_ELEARNING |
1.html  | 2002-01-31 18:08:14+08
  69718 |   61453 | uZuNbGXsWnXXRECH6PGeFdtf | COG_001_ELEARNING |
15.html | 2002-01-31 18:09:30+08
  69719 |   61453 | uZuNbGXsWnXXRECH6PGeFdtf | COG_001_ELEARNING |
16.html | 2002-01-31 18:07:49+08



The oid correctly reflects the order of the insertion of the rows...
but look at the timestamp - the last row has a timestamp _2 minutes
before_ the previous row. How could this be happening? We know row
69719 was inserted _after_ 69718, by probably about 30 seconds.

Thanks much.

Elaine Lindelef

...
> The oid correctly reflects the order of the insertion of the rows...
> but look at the timestamp - the last row has a timestamp _2 minutes
> before_ the previous row. How could this be happening? We know row
> 69719 was inserted _after_ 69718, by probably about 30 seconds.

The timestamp provided as a result of evaluating 'now' is the time of
the start of the transaction, not the instantaneous wall clock time (if
you want the latter there is a function to provide it).

So, the times will reflect the time the transaction was started, while
the OID will reflect the order in which the insert/update actually
happened within the transaction.

hth

                    - Thomas

At 04:14 AM 01-02-2002 +0000, Thomas Lockhart wrote:
>...
>> The oid correctly reflects the order of the insertion of the rows...
>> but look at the timestamp - the last row has a timestamp _2 minutes
>> before_ the previous row. How could this be happening? We know row
>> 69719 was inserted _after_ 69718, by probably about 30 seconds.
>
>The timestamp provided as a result of evaluating 'now' is the time of
>the start of the transaction, not the instantaneous wall clock time (if
>you want the latter there is a function to provide it).
>
>So, the times will reflect the time the transaction was started, while
>the OID will reflect the order in which the insert/update actually
>happened within the transaction.

Do postgresql backends still preallocate ranges of OIDs?

Link.

Lincoln Yeoh <lyeoh@pop.jaring.my> writes:
> Do postgresql backends still preallocate ranges of OIDs?

Good point ... but in 7.1 they don't anymore.  There's just one shared
OID counter.

            regards, tom lane

>...
> > The oid correctly reflects the order of the insertion of the rows...
> > but look at the timestamp - the last row has a timestamp _2 minutes
> > before_ the previous row. How could this be happening? We know row
> > 69719 was inserted _after_ 69718, by probably about 30 seconds.
>
>The timestamp provided as a result of evaluating 'now' is the time of
>the start of the transaction, not the instantaneous wall clock time (if
>you want the latter there is a function to provide it).
>
>So, the times will reflect the time the transaction was started, while
>the OID will reflect the order in which the insert/update actually
>happened within the transaction.
>
>hth
>
>                    - Thomas

The beginning of the transactions was definitely in the same order as
the OID reflects, and I'm quite sure the previous transaction was
completed before the next connection was started as well.

Elaine