| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Florian Pflug <fgp(at)phlo(dot)org> |
| Cc: | Kevin Grittner <kgrittn(at)ymail(dot)com>, Nick Barnes <nickbarnes01(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
| Subject: | Re: Question about RI checks |
| Date: | 2014-10-24 18:24:12 |
| Message-ID: | CA+TgmoYHO=r62KMS5TwJLkOJm-JbOvV6gEA99BWxLpdDkrWqKA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, Oct 24, 2014 at 2:12 PM, Florian Pflug <fgp(at)phlo(dot)org> wrote:
>> What about doing one scan using SnapshotAny and then testing each
>> returned row for visibility under both relevant snapshots? See
>> whether there is any tuple for which they disagree.
>
> See my other mail - testing whether the snapshots agree isn't enough,
> you'd have to check whether there could have been *any* snapshot taken
> between the two which would see a different result.
Oh, hmm. I had thought what I was proposing was strong enough to
handle that case, but now I see that it isn't. However, I'm not
entirely sure that it's the RI code's job to prevent such cases, or at
least not when the transaction isolation level is less than
serializable. Is there an argument that the anomaly that results is
unacceptable at REPEATABLE READ?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2014-10-24 18:28:27 | Re: How ugly would this be? (ALTER DATABASE) |
| Previous Message | Florian Pflug | 2014-10-24 18:12:00 | Re: Question about RI checks |