From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Ashutosh Sharma <ashu(dot)coek88(at)gmail(dot)com> |
Cc: | Prabhat Sahu <prabhat(dot)sahu(at)enterprisedb(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: tableam vs. TOAST |
Date: | 2019-11-07 14:05:13 |
Message-ID: | CA+TgmoY9_SKehXO+fsBoO2g3_wKnC8PdH2YH4E=qu_J6CEuapQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Nov 7, 2019 at 1:15 AM Ashutosh Sharma <ashu(dot)coek88(at)gmail(dot)com> wrote:
> @Robert, Myself and Prabhat have tried running the test-cases that
> caused the checkpointer process to crash earlier multiple times but we
> are not able to reproduce it both with and without the patch. However,
> from the stack trace shared earlier by Prabhat, it is clear that the
> checkpointer process panicked due to fsync failure. But, there is no
> further data to know the exact reason for the fsync failure. From the
> code of checkpointer process (basically the function to process fsync
> requests) it is understood that, the checkpointer process can PANIC
> due to one of the following two reasons.
Oh, I didn't realize this was a panic due to an fsync() failure when I
looked at the stack trace before. I think it's concerning that
fsync() failed on Prabhat's machine, and it would be interesting to
know why that happened, but I don't see how this patch could possibly
*cause* fsync() to fail, so I think we can say that whatever is
happening on his machine is unrelated to this patch -- and probably
also unrelated to PostgreSQL.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2019-11-07 14:12:29 | Re: TAP tests aren't using the magic words for Windows file access |
Previous Message | Andrew Dunstan | 2019-11-07 14:04:21 | Re: TAP tests aren't using the magic words for Windows file access |