Re: Sync Rep: First Thoughts on Code - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: Sync Rep: First Thoughts on Code
Date
Msg-id 4945675C.7060607@enterprisedb.com
Whole thread Raw
In response to Re: Sync Rep: First Thoughts on Code  (Mark Mielke <mark@mark.mielke.cc>)
Responses Re: Sync Rep: First Thoughts on Code  (Mark Mielke <mark@mark.mielke.cc>)
List pgsql-hackers
Mark Mielke wrote:
> 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)?

Yes. PostgreSQL does guarantee that, and I would expect any other DBMS 
to do the same.

--   Heikki Linnakangas  EnterpriseDB   http://www.enterprisedb.com


pgsql-hackers by date:

Previous
From: "Pavel Stehule"
Date:
Subject: Re: WIP: default values for function parameters
Next
From: Alvaro Herrera
Date:
Subject: Re: So, why shouldn't SET CONSTRAINTS set a transaction snapshot?