Thank you for noticing me of that. Is there any way to know how a bug report has been concluded? Or should I search -hackers for a corresponding thread?
At Thu, 26 Apr 2018 21:13:48 +0900, Michael Paquier <mich...@paquier.xyz> wrote in <20180426121348.ga2...@paquier.xyz> > On Thu, Apr 26, 2018 at 07:53:04PM +0900, Kyotaro HORIGUCHI wrote: > > I think this behavior is a bug. XLogReadRecord is considering the > > case but palloc_extended() breaks it. So in the attached, add a > > new flag MCXT_ALLOC_NO_PARAMERR to palloc_extended() and > > allocate_recordbuf calls it with the new flag. That alone fixes > > the problem. However, the patch frees read state buffer facing > > errorneous records since such records can leave a too-large > > buffer allocated. > > This problem is already discussed here: > https://commitfest.postgresql.org/18/1516/ > > And here is the thread: > https://www.postgresql.org/message-id/flat/0A3221C70F24FB45833433255569204D1F8B57AD@G01JPEXMBYT05 > > Tsunakawa-san and I discussed a couple of approaches. Extending > palloc_extended so as an incorrect length does not result in an error is > also something that crossed by mind, but the length handling is > different on the backend and the frontend, so I discarded the idea you > are proposing here and instead relied on a check with AllocSizeIsValid, > which gives a more simple patch: > https://www.postgresql.org/message-id/20180314052753.GA16179%40paquier.xyz Yeah, perhaps all approaches in the thread came to my mind but choosed different one. I'm fine with the approach in the thread. > This got no interest from committers yet unfortunately, but I think that > this is a real problem which should be back-patched :( Several other WAL-related fixes are also waiting to be picked up.. regards. -- Kyotaro Horiguchi NTT Open Source Software Center
