| From: | "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> |
|---|---|
| To: | <simon(at)2ndQuadrant(dot)com>,<heikki(dot)linnakangas(at)enterprisedb(dot)com>, "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> |
| Cc: | <drkp(at)csail(dot)mit(dot)edu>,<fgp(at)phlo(dot)org>, <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: SSI and Hot Standby |
| Date: | 2011-01-21 14:43:27 |
| Message-ID: | 4D3947300200002500039984@gw.wicourts.gov |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
"Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> wrote:
> (1) A read write transaction might need to be canceled to
> prevent the view of the data a committed read only transaction has
> already seen from becoming inconsistent. (Dan's example)
And this one seems entirely a theoretical possibility. I spent a
little time looking it over, and I don't see how it could be made to
work from hot standbys without an unbounded flow of predicate lock
information from all standbys to the master *plus* blocking commits
on the master for the duration of the longest round trip latency to
any standby. I think we can call this one dead on arrival.
-Kevin
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2011-01-21 14:51:26 | Re: More detailed auth info |
| Previous Message | Magnus Hagander | 2011-01-21 14:39:03 | More detailed auth info |