| From: | "Albe Laurenz" <laurenz(dot)albe(at)wien(dot)gv(dot)at> |
|---|---|
| To: | "Kevin Grittner *EXTERN*" <Kevin(dot)Grittner(at)wicourts(dot)gov>, <pgsql-hackers(at)postgresql(dot)org> |
| Cc: | <mjc(at)it(dot)usyd(dot)edu(dot)au> |
| Subject: | Re: Serializable Isolation without blocking |
| Date: | 2009-05-07 14:40:47 |
| Message-ID: | D960CB61B694CF459DCFB4B0128514C202FF65B3@exadv11.host.magwien.gv.at |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Kevin Grittner wrote:
> > Where does T1 select rows that were modified by T0? It selects only
> > one row, the one it modified itself, right?
>
> You have to select it to know whether to count it, right?
We are getting closer.
So an SIREAD lock is taken for every row that is examined during
the execution of an execution plan?
Ah.
What if there is an index on the "ishighlander" row?
Then an index scan would find only one candidate to examine,
and the other rows would not even be touched by the execution plan.
Then how would they contract an SIREAD lock?
Yours,
Laurenz Albe
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Heikki Linnakangas | 2009-05-07 14:54:33 | Re: BUG #4796: Recovery followed by backup creates unrecoverable WAL-file |
| Previous Message | Kevin Grittner | 2009-05-07 14:27:13 | Re: Serializable Isolation without blocking |