Re: Hot standby, recovery infra
От | Heikki Linnakangas |
---|---|
Тема | Re: Hot standby, recovery infra |
Дата | |
Msg-id | 498174C6.5000407@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: Hot standby, recovery infra (Simon Riggs <simon@2ndQuadrant.com>) |
Ответы |
Re: Hot standby, recovery infra
|
Список | pgsql-hackers |
Simon Riggs wrote: > On Thu, 2009-01-29 at 10:36 +0900, Fujii Masao wrote: >> Hi, >> >> On Wed, Jan 28, 2009 at 11:19 PM, Fujii Masao <masao.fujii@gmail.com> wrote: >>>> I feel quite good about this patch now. Given the amount of code churn, it >>>> requires testing, and I'll read it through one more time after sleeping over >>>> it. Simon, do you see anything wrong with this? >>> I also read this patch and found something odd. I apologize if I misread it.. >> If archive recovery fails after it reaches the last valid record >> in the last unfilled WAL segment, subsequent recovery might cause >> the following fatal error. This is because minSafeStartPoint indicates >> the end of the last unfilled WAL segment which subsequent recovery >> cannot reach. Is this bug? (I'm not sure how to fix this problem >> because I don't understand yet why minSafeStartPoint is required.) >> >>> FATAL: WAL ends before end time of backup dump > > I think you're right. We need a couple of changes to avoid confusing > messages. Hmm, we could update minSafeStartPoint in XLogFlush instead. That was suggested when the idea of minSafeStartPoint was first thought of. Updating minSafeStartPoint is analogous to flushing WAL: minSafeStartPoint must be advanced to X before we can flush a data pgse with LSN X. To avoid excessive controlfile updates, whenever we update minSafeStartPoint, we can update it to the latest WAL record we've read. Or we could simply ignore that error if we've reached minSafeStartPoint - 1 segment, assuming that even though minSafeStartPoint is higher, we can't have gone past the end of valid WAL records in the last segment in previous recovery either. But that feels more fragile. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: