| From: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Heikki Linnakangas <heikki(at)enterprisedb(dot)com>, Gregory Stark <stark(at)enterprisedb(dot)com>, "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, Jeff Trout <threshar(at)threshar(dot)is-a-geek(dot)com>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: [GENERAL] Slow PITR restore |
| Date: | 2007-12-13 21:55:33 |
| Message-ID: | 1197582933.4255.1920.camel@ebony.site |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general pgsql-hackers |
On Thu, 2007-12-13 at 16:41 -0500, Tom Lane wrote:
> Recovery is inherently one of the least-exercised parts of the system,
> and it gets more so with each robustness improvement we make elsewhere.
> Moreover, because it is fairly dumb, anything that does go wrong will
> likely result in silent data corruption that may not be noted until much
> later. Any bugs we introduce into recovery will be very hard to find
> ... and timing-dependent ones will be damn near impossible.
>
> So in my mind the watchword has got to be KISS. If that means that
> recovery isn't terribly speedy, so be it. I'd far rather get the
> right answer slower.
Very much agreed, and really the real reason the main recovery code is
essentially untouched for so long. That thought was #1 priority when
writing PITR. Thanks for reminding me/us.
--
Simon Riggs
2ndQuadrant http://www.2ndQuadrant.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Heikki Linnakangas | 2007-12-13 21:57:29 | Re: [GENERAL] Slow PITR restore |
| Previous Message | Joshua D. Drake | 2007-12-13 21:54:58 | Re: [GENERAL] Slow PITR restore |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Heikki Linnakangas | 2007-12-13 21:57:29 | Re: [GENERAL] Slow PITR restore |
| Previous Message | Joshua D. Drake | 2007-12-13 21:54:58 | Re: [GENERAL] Slow PITR restore |