Re: BUG #18146: Rows reappearing in Tables after Auto-Vacuum Failure in PostgreSQL on Windows
От | Thomas Munro |
---|---|
Тема | Re: BUG #18146: Rows reappearing in Tables after Auto-Vacuum Failure in PostgreSQL on Windows |
Дата | |
Msg-id | CA+hUKG+_ubs52OfrFBK7sH-X5pk6Y7BbwnXOgqndGKddLxZa3w@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: BUG #18146: Rows reappearing in Tables after Auto-Vacuum Failure in PostgreSQL on Windows (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: BUG #18146: Rows reappearing in Tables after Auto-Vacuum Failure in PostgreSQL on Windows
|
Список | pgsql-bugs |
On Fri, Oct 20, 2023 at 8:50 AM Robert Haas <robertmhaas@gmail.com> wrote: > I don't understand what you mean about stunning the checkpointer, but I just meant that, with your change, we ask the checkpointer to wait for our signal if it reaches that code path and then while it's snoozing we call register_dirty_segment(). I wanted to report that I'd checked that it copes with the request queue being full, by falling back to calling fsync() itself, which is good news because if it instead waited for the checkpointer to drain the request queue instead (an available option), we'd have a potential deadlock. > here are some patches. 0001: LGTM, except in the commit message "By setting XLOG_CHKPT_START," s/XLOG/DELAY/. 0002: LGTM Now I wonder if we will get occasional PANIC reports from Windows users. I might prepare one of those retry wrappers...
В списке pgsql-bugs по дате отправления: