Re: Sync Rep: First Thoughts on Code
От | Heikki Linnakangas |
---|---|
Тема | Re: Sync Rep: First Thoughts on Code |
Дата | |
Msg-id | 4945675C.7060607@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: Sync Rep: First Thoughts on Code (Mark Mielke <mark@mark.mielke.cc>) |
Ответы |
Re: Sync Rep: First Thoughts on Code
|
Список | 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 по дате отправления: