Re: [HACKERS] WIP: long transactions on hot standby feedback replica/ proof of concept

Поиск
Список
Период
Сортировка
От Alexander Korotkov
Тема Re: [HACKERS] WIP: long transactions on hot standby feedback replica/ proof of concept
Дата
Msg-id CAPpHfdtC7HHOkFY2-hsU4-oBmY7CY1Zytgd8t53u+gichF22_A@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] WIP: long transactions on hot standby feedback replica/ proof of concept  (Masahiko Sawada <sawada.mshk@gmail.com>)
Ответы Re: [HACKERS] WIP: long transactions on hot standby feedback replica/ proof of concept
Re: [HACKERS] WIP: long transactions on hot standby feedback replica/ proof of concept
Список pgsql-hackers
Дерево обсуждения
On Tue, Oct 31, 2017 at 5:16 AM, Masahiko Sawada <sawada.mshk@gmail.com> wrote:
On Mon, Oct 30, 2017 at 10:16 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Tue, Oct 24, 2017 at 1:26 PM, Ivan Kartyshov
> <i.kartyshov@postgrespro.ru> wrote:
>> Hello. I made some bugfixes and rewrite the patch.
>
> I don't think it's a good idea to deliberately leave the state of the
> standby different from the state of the  master on the theory that it
> won't matter.  I feel like that's something that's likely to come back
> to bite us.

I agree with Robert. What happen if we intentionally don't apply the
truncation WAL and switched over? If we insert a tuple on the new
master server to a block that has been truncated on the old master,
the WAL apply on the new standby will fail? I guess there are such
corner cases causing failures of WAL replay after switch-over.

Yes, that looks dangerous.  One approach to cope that could be teaching heap redo function to handle such these situations.  But I expect this approach to be criticized for bad design.  And I understand fairness of this criticism.

However, from user prospective of view, current behavior of hot_standby_feedback is just broken, because it both increases bloat and doesn't guarantee that read-only query on standby wouldn't be cancelled because of vacuum.  Therefore, we should be looking for solution: if one approach isn't good enough, then we should look for another approach.

I can propose following alternative approach: teach read-only queries on hot standby to tolerate concurrent relation truncation.  Therefore, when non-existent heap page is accessed on hot standby, we can know that it was deleted by concurrent truncation and should be assumed to be empty.  Any thoughts?

------
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company 

В списке pgsql-hackers по дате отправления: