Re: Connections hang indefinitely while taking a gin index's LWLockbuffer_content lock
От | Simon Riggs |
---|---|
Тема | Re: Connections hang indefinitely while taking a gin index's LWLockbuffer_content lock |
Дата | |
Msg-id | CANP8+jKsyRSaAxi1TchqFGG1XkeWe-FGeiSgsueFmSVxyf3_eQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Connections hang indefinitely while taking a gin index's LWLockbuffer_content lock (Alexander Korotkov <aekorotkov@gmail.com>) |
Список | pgsql-hackers |
On Thu, 21 Mar 2019 at 15:18, Alexander Korotkov <aekorotkov@gmail.com> wrote:
On Thu, Mar 21, 2019 at 9:26 PM Simon Riggs <simon@2ndquadrant.com> wrote:
> It's been pointed out to me that 52ac6cd2d0cd70e01291e0ac4ee6d068b69bc478
> introduced a WAL incompatibility that has not been flagged.
>
> In ginRedoDeletePage() we use the struct directly to read the WAL record, so if a WAL record was written prior to 52ac6cd2d0cd70e01291e0ac4ee6d068b69bc478, yet read by code at 52ac6cd2d0cd70e01291e0ac4ee6d068b69bc478 or later then we will have problems, since deleteXid will not be set correctly.
>
> It seems this should not have been backpatched.
>
> Please give your assessment.
Oh, right. This is my fault.
However, I think this still can be backpatched correctly. We can
determine whether xlog record data contains deleteXid by its size.
See the attached patch. I haven't test this yet. I'm going to test
it. If OK, then push.
Patch looks like it will work.
I'd prefer to see a tighter test, since the length should either be the old or new length, no other.
Thanks
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: