Re: Review for GetWALAvailability()
От | Fujii Masao |
---|---|
Тема | Re: Review for GetWALAvailability() |
Дата | |
Msg-id | 17a69cfe-f1c1-a416-ee25-ae15427c69eb@oss.nttdata.com обсуждение исходный текст |
Ответ на | Re: Review for GetWALAvailability() (Alvaro Herrera <alvherre@2ndquadrant.com>) |
Ответы |
Re: Review for GetWALAvailability()
|
Список | pgsql-hackers |
On 2020/06/25 3:27, Alvaro Herrera wrote: > Thanks for those corrections. > > I have pushed this. I think all problems Masao-san reported have been > dealt with, so we're done here. Sorry for my late to reply here... Thanks for committing the patch and improving the feature! /* * Find the oldest extant segment file. We get 1 until checkpoint removes * the first WAL segment file since startup, which causes the status being * wrong under certain abnormal conditions but that doesn't actually harm. */ oldestSeg = XLogGetLastRemovedSegno() + 1; I see the point of the above comment, but this can cause wal_status to be changed from "lost" to "unreserved" after the server restart. Isn't this really confusing? At least it seems better to document that behavior. Or if we *can ensure* that the slot with invalidated_at set always means "lost" slot, we can judge that wal_status is "lost" without using fragile XLogGetLastRemovedSegno(). Thought? Or XLogGetLastRemovedSegno() should be fixed so that it returns valid value even after the restart? Regards, -- Fujii Masao Advanced Computing Technology Center Research and Development Headquarters NTT DATA CORPORATION
В списке pgsql-hackers по дате отправления: