Re: Sync Rep: First Thoughts on Code

From: Greg Stark <greg(dot)stark(at)enterprisedb(dot)com>
To: Mark Mielke <mark(at)mark(dot)mielke(dot)cc>
Cc: Markus Wanner <markus(at)bluegap(dot)ch>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, "aidan(at)highrise(dot)ca" <aidan(at)highrise(dot)ca>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Sync Rep: First Thoughts on Code
Date: 2008-12-15 00:21:51
Message-ID: 1D6BF47A-7B0B-463F-B53C-D46910F566B2@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)mark(dot)mielke(dot)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(at)mielke(dot)cc>
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Corey Horton 2008-12-15 00:39:39 Re: Re: [SQL] array_to_string(anyarray, text) that was working in 8.1 is not working in 8.3
Previous Message Mark Mielke 2008-12-14 23:53:01 Re: Sync Rep: First Thoughts on Code