From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Steve Dodd" <steve(at)streetcontxt(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Transaction completion timing |
Date: | 2014-09-24 18:01:09 |
Message-ID: | 20447.1411581669@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
"Steve Dodd" <steve(at)streetcontxt(dot)com> writes:
> Say we have two transactions run sequentially: T1 writes some data, and T2 reads the written data. There is a non-zero time delay between the apparent T1 commit, and the subsequent T2 query.
> Is there any guarantee that the data written in T1 will be visible to the query in T2?
> We have a situation in our system where it would appear that the answer is NO.
Extremely hard to believe. There is a very well-defined point where the
transaction's effects become visible to other transactions, and that is
certainly before the commit is reported as complete to the client.
I suspect if you dig into it you'll find that your client-side code
is doing something unexpected.
Also worth checking is that "T2" is actually a transaction, and not
a single statement within a serializable-mode transaction. In the latter
case it would see the database state as of the transaction's snapshot,
which might precede T1's commit.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Daniel Lenski | 2014-09-24 18:06:21 | Re: Why can't I select un-grouped columns when grouping by a (non-primary) unique key? |
Previous Message | Steve Dodd | 2014-09-24 17:52:17 | Transaction completion timing |