Re: Repeatable read and serializable transactions see data committed after tx start

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com>
Cc: Álvaro Hernández Tortosa <aht(at)8Kdata(dot)com>, Craig Ringer <craig(at)2ndquadrant(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Repeatable read and serializable transactions see data committed after tx start
Date: 2014-11-06 06:12:52
Message-ID: 12606.1415254372@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com> writes:
> Hmm... we do have transaction_timestamp(); perhaps we could leave that as the time BEGIN executed and shift everything else to use the snapshot time.

It's not possible to take a timestamp that *exactly* matches the snapshot
time. We could rearrange the code so that we ask the kernel for
timeofday just before or after capturing some relevant snapshot, but
there's still going to be some skew there.

In any case, I believe we document those timestamps as being the time of
arrival of a command from the client, not in terms of any snapshots.
To the extent that people use now() to represent the time of insertion of
data, I think the command arrival time is arguably the best definition.
Delaying it until the server code gets around to capturing a snapshot
would not be an improvement.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2014-11-06 07:50:45 Re: tracking commit timestamps
Previous Message Tom Lane 2014-11-06 06:03:31 Re: Convert query plan to sql query