Re: Standby corruption after master is restarted
От
Michael Paquier
Тема
Re: Standby corruption after master is restarted
Дата
Msg-id
20180426121348.GA2365@paquier.xyz
Ответ на
Re: Standby corruption after master is restarted (Kyotaro HORIGUCHI)
Список
Дерево обсуждения
[BUGS] Standby corruption after master is restarted Emre Hasegeli <emre@hasegeli.com>
Re: [BUGS] Standby corruption after master is restarted Andres Freund <andres@anarazel.de>
Re: [BUGS] Standby corruption after master is restarted Emre Hasegeli <emre@hasegeli.com>
Re: Standby corruption after master is restarted Emre Hasegeli <emre@hasegeli.com>
Re: Standby corruption after master is restarted Tomas Vondra <tomas.vondra@2ndquadrant.com>
Re: Standby corruption after master is restarted Emre Hasegeli <emre@hasegeli.com>
Re: Standby corruption after master is restarted Tomas Vondra <tomas.vondra@2ndquadrant.com>
Re: Standby corruption after master is restarted Emre Hasegeli <emre@hasegeli.com>
Re: Standby corruption after master is restarted Tomas Vondra <tomas.vondra@2ndquadrant.com>
Re: Standby corruption after master is restarted Emre Hasegeli <emre@hasegeli.com>
Re: Standby corruption after master is restarted Tomas Vondra <tomas.vondra@2ndquadrant.com>
Re: Standby corruption after master is restarted Emre Hasegeli <emre@hasegeli.com>
Re: Standby corruption after master is restarted Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>
Re: Standby corruption after master is restarted Michael Paquier <michael@paquier.xyz>
Re: Standby corruption after master is restarted Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>
Re: Standby corruption after master is restarted Michael Paquier <michael@paquier.xyz>
Re: Standby corruption after master is restarted Tomas Vondra <tomas.vondra@2ndquadrant.com>
Re: Standby corruption after master is restarted Emre Hasegeli <emre@hasegeli.com>
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 This got no interest from committers yet unfortunately, but I think that this is a real problem which should be back-patched :( -- Michael
В списке pgsql-bugs по дате отправления