Re: [BUG] Panic due to incorrect missingContrecPtr after promotion
От | Robert Haas |
---|---|
Тема | Re: [BUG] Panic due to incorrect missingContrecPtr after promotion |
Дата | |
Msg-id | CA+Tgmob6xw_JA7fpivk7JBiJcV5YO4xfeiZk3X+sbJEePTzgTg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [BUG] Panic due to incorrect missingContrecPtr after promotion (Kyotaro Horiguchi <horikyota.ntt@gmail.com>) |
Список | pgsql-hackers |
On Mon, Jun 20, 2022 at 9:35 PM Kyotaro Horiguchi <horikyota.ntt@gmail.com> wrote: > Unfortunately it doesn't work because we read a record already known > to be complete again at the end of recovery. It is the reason of > "abortedRecPtr < xlogreader->EndRecPtr" in my PoC patch. Without it, > abrotedRecPtr is erased when it is actually needed. I don't like that > expedient-looking condition, but the strict condition for resetting > abortedRecPtr is iff "we have read a complete record at the same or > grater LSN ofabortedRecPtr"... Yeah, we need to work around that somehow. I noticed the record-rereading behavior when I was working on some patches for this release cycle and I think what we ought to do is get rid of that. It serves no purpose other than to make things complicated. However, we shouldn't back-patch a change like that, I think, so we'll need to work around the issue somehow. Perhaps it'd be better to return these values to the caller somehow and then the caller can decide whether to save them based on context. The last re-read can choose not to do so. -- Robert Haas EDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: