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

From Greg Stark
Subject Re: Sync Rep: First Thoughts on Code
Date
Msg-id 1D6BF47A-7B0B-463F-B53C-D46910F566B2@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
When the database says the data is committed it has to mean the data  
is really committed. Imagine if you looked at a bank account balance  
after withdrawing all the money and saw a balance which didn't reflect  
the withdrawal and allowed you to withdraw more money again...

-- 
Greg


On 14 Dec 2008, at 14:44, Mark Mielke <mark@mark.mielke.cc> 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)? 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>
>
>
> -- 
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers


pgsql-hackers by date:

Previous
From: Mark Mielke
Date:
Subject: Re: Sync Rep: First Thoughts on Code
Next
From: Corey Horton
Date:
Subject: Re: Re: [SQL] array_to_string(anyarray, text) that was working in 8.1 is not working in 8.3