| From: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
|---|---|
| To: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
| Cc: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Hot standby, recovery infra |
| Date: | 2009-01-29 12:54:42 |
| Message-ID: | 1233233682.3983.5.camel@ebony.2ndQuadrant |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, 2009-01-29 at 12:22 +0200, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > My proposed fix for Fujii-san's minSafeStartPoint bug is to introduce
> > another control file state DB_IN_ARCHIVE_RECOVERY_BASE. This would show
> > that we are still recovering up to the point of the end of the base
> > backup. Once we reach minSafeStartPoint we then switch state to
> > DB_IN_ARCHIVE_RECOVERY, and set baseBackupReached boolean, which then
> > enables writing new minSafeStartPoints when we open new WAL files in the
> > future.
>
> I don't see how that helps, the bug has nothing to with base backups.
Sorry, disagree.
> It
> comes from the fact that we set minSafeStartPoint beyond the actual end
> of WAL, if the last WAL segment is only partially filled (= fails CRC
> check at some point). If we crash after setting minSafeStartPoint like
> that, and then restart recovery, we'll get the error.
Look again please. My proposal would avoid the error when it is not
relevant, yet keep it when it is (while recovering base backups).
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andrew Dunstan | 2009-01-29 13:06:44 | Re: mingw check hung |
| Previous Message | Heikki Linnakangas | 2009-01-29 12:21:11 | Re: Hot standby, recovery infra |