Re: Review for GetWALAvailability()
От | Alvaro Herrera |
---|---|
Тема | Re: Review for GetWALAvailability() |
Дата | |
Msg-id | 20200625035718.GA28721@alvherre.pgsql обсуждение исходный текст |
Ответ на | Re: Review for GetWALAvailability() (Fujii Masao <masao.fujii@oss.nttdata.com>) |
Ответы |
Re: Review for GetWALAvailability()
|
Список | pgsql-hackers |
On 2020-Jun-25, Fujii Masao wrote: > /* > * 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. Hmm. > 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? Hmm, this sounds compelling -- I think it just means we need to ensure we reset invalidated_at to zero if the slot's restart_lsn is set to a correct position afterwards. I don't think we have any operation that does that, so it should be safe -- hopefully I didn't overlook anything? Neither copy nor advance seem to work with a slot that has invalid restart_lsn. > Or XLogGetLastRemovedSegno() should be fixed so that it returns valid > value even after the restart? This seems more work to implement. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: