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()  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Список 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 по дате отправления:

Предыдущее
От: Bharath Rupireddy
Дата:
Сообщение: Re: Parallel copy
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: Review for GetWALAvailability()