On Sat, Feb 2, 2019 at 4:42 AM Chengchao Yu <chen...@microsoft.com> wrote: > > Hi Amit, Thomas, > > Thank you very much for your feedbacks! Apologizes but I just saw both > messages. > > > We generally reserve the space in a relation before attempting to write, so > > not sure how you are able to hit the disk full situation via mdwrite. If > > you see the description of the function, that also indicates same. > > Absolutely agree, this isn’t a PG issue. Issue manifest for us at Microsoft > due to our own storage layer which treat mdextend() actions as setting length > of the file only. We have a workaround, and any change isn’t needed for > Postgres. > > > I am not telling that mdwrite can never lead to error, but just trying to > > understand the issue you actually faced. I haven't read your proposed > > solution yet, let's first try to establish the problem you are facing. > > We see transient IO errors reading a block where PG instance gets dead-lock > in single user mode until we kill the instance. The stack trace below shows > the behavior which is when mdread() failed with buffer holding its lw-lock. > This happens because in single user mode there is no call back to release the > lock and when AbortBufferIO() tries to acquire the same lock again, it will > wait for the lock indefinitely. >
I think you can register your patch for next CF [1] so that we don't forget about it. [1] - https://commitfest.postgresql.org/22/ -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
