Re: page is uninitialized --- fixing

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