On 11/5/14, 6:04 PM, Álvaro Hernández Tortosa wrote:
On 05/11/14 17:46, Jim Nasby wrote:
On 11/4/14, 6:11 PM, Álvaro Hernández Tortosa wrote:
Should we improve then the docs stating this more clearly? Any objection
to do this?
If we go that route we should also mention that now() will no longer be doing
what you probably hope it would (AFAIK it's driven by BEGIN and not the first
snapshot).
If I understand you correctly, you mean that if we add a note to the
documentation stating that the transaction really freezes when you do the first
query, people would expect now() to be also frozen when the first query is
done, which is not what happens (it's frozen at tx start). Then, yes, you're
right, probably *both* the isolation levels and the now() function
documentation should be patched to become more precise.
Bingo.
Hrm, is there anything else that differs between the two?
Perhaps we should change how now() works, but I'm worried about what that might
do to existing applications...
Perhaps, I also believe it might not be good for existing applications,
but it definitely has a different freeze behavior, which seems inconsistent too.
Yeah, I'd really rather fix it...
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.
Or we could do the opposite. I suspect that would be more likely to cause data
quality errors, but anyone that treats timestamps as magic values is going to
have those anyway.
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
