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 -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
