Mark Mielke wrote:
> Forget replication - even for the exact same server - I don't expect
> that if I commit from one session, I will be able to see the change
> immediately from my other session or a new session that I just opened.
> Perhaps this is often stable to rely on this, and it is useful for the
> database server to minimize the window during which the commit becomes
> visible to others, but I think it's a false expectation from the start
> that it absolutely will be immediately visible to another session. I'm
> thinking of situations where some part of the table is in cache. The
> only way the commit can communicate that the new transaction is
> available is by during communication between the processes or threads,
> or between the multiple CPUs on the machine. Do I want every commit to
> force each session to become fully in alignment before my commit
> completes? Does PostgreSQL make this guarantee today? I bet it doesn't
> if you look far enough into the guts. It might be very fast - I don't
> think it is infinitely fast.
FYI: I haven't been able to prove this. Multiple sessions running on my
dual-core CPU seem to be able to see the latest commits before they
begin executing. Am I wrong about this? Does PostgreSQL provide a
intentional guarantee that a commit from one session that completes
immediately followed by a query from another session will always find
the commit effect visible (provide the transaction isolation level
doesn't get in the way)? Or is the machine and algorithms just fast
enough that by the time it executes the query (up to 1 ms later) the
commit is always visible in practice?
Cheers,
mark
--
Mark Mielke <mark@mielke.cc>
