Re: page is uninitialized --- fixing

Поиск
Список
Период
Сортировка
От Stefan Kaltenbrunner
Тема Re: page is uninitialized --- fixing
Дата
Msg-id 47EF6161.7030201@kaltenbrunner.cc
обсуждение исходный текст
Ответ на Re: page is uninitialized --- fixing  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-general
Tom Lane wrote:

> This is not entirely out of the question, because of the designed-in
> property that a freshly initialized page is only inserted into by
> the backend that got it --- no one else will know there is any
> free space in it until VACUUM first passes over it.  So if there
> are a lot of different sessions writing into this table you don't
> need to assume more than about one tuple per page.  Still, it's
> kinda hard to believe that the first two backends could remain stuck
> for so long as to let ~800 other insertions happen.

depending on how the multipathing and recovery works on that particular
SAN/OS combination it might very well be that some processes are getting
  their IO hold much longer than some other processes.
Maybe the  first two backends had IO in-flight and the OS needed time to
requeue/resend those after the SAN recovered and "new" backends were
able to do IO immediately ?


Stefan

В списке pgsql-general по дате отправления:

Предыдущее
От: Reece Hart
Дата:
Сообщение: Re: Survey: renaming/removing script binaries (createdb, createuser...)
Следующее
От: Tino Wildenhain
Дата:
Сообщение: Re: Survey: renaming/removing script binaries (createdb, createuser...)