| From: | Nicolas Barbier <nicolas(dot)barbier(at)gmail(dot)com> |
|---|---|
| To: | Florian Pflug <fgp(at)phlo(dot)org> |
| Cc: | Dan Ports <drkp(at)csail(dot)mit(dot)edu>, Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, pgsql-hackers(at)postgresql(dot)org, JanWieck(at)yahoo(dot)com |
| Subject: | Re: Exposing the Xact commit order to the user |
| Date: | 2010-05-25 19:35:36 |
| Message-ID: | AANLkTik1w8IH91TXq7DcuVL2WDjW51x_1TUshggmUX93@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
2010/5/25 Florian Pflug <fgp(at)phlo(dot)org>:
> On May 25, 2010, at 20:18 , Dan Ports wrote:
>
>> T3, which is a read-only transaction, sees the incremented date and an
>> empty list of receipts. But T1 later commits a new entry in the
>> receipts table with the old date. No serializable ordering allows this.
>>
>> However, if T3 hadn't performed its read, there'd be no problem; we'd
>> just serialize T1 before T2 and no one would be the wiser.
>
> Hm, so in fact SSI sometimes allows the database to be inconsistent, but only as long as nobody tries to observe it?
I would not call this an inconsistent state: it would become
inconsistent only after someone (e.g., T3) has observed it _and_ T1
commits.
Nicolas
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Hector Beyers | 2010-05-25 19:39:44 | Fwd: Hiding data in postgresql |
| Previous Message | Florian Pflug | 2010-05-25 19:35:13 | Re: Exposing the Xact commit order to the user |