Re: Skipping logical replication transactions on subscriber side

Поиск
Список
Период
Сортировка
От David G. Johnston
Тема Re: Skipping logical replication transactions on subscriber side
Дата
Msg-id CAKFQuwY=7v9xyb4A4m6dBnTJyRXvOFnpqnTgauL1US=WO_Ukdg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Skipping logical replication transactions on subscriber side  (Peter Eisentraut <peter.eisentraut@enterprisedb.com>)
Ответы Re: Skipping logical replication transactions on subscriber side  (Masahiko Sawada <sawada.mshk@gmail.com>)
Список pgsql-hackers
On Tue, Jan 25, 2022 at 5:52 AM Peter Eisentraut <peter.eisentraut@enterprisedb.com> wrote:
On 25.01.22 06:18, Amit Kapila wrote:
> I think to avoid this we can send a message to clear this (at least to
> clear XID in the view) after skipping the xact but there is no
> guarantee that it will be received by the stats collector.
> Additionally, the worker can periodically (say after every N (100,
> 500, etc) successful transaction) send a clear message after
> successful apply. This will ensure that eventually the error entry
> will be cleared.

Well, I think we need *some* solution for now.  We can't leave a footgun
where you say, "skip transaction 700", somehow transaction 700 doesn't
happen, the whole thing gets forgotten, but then 3 months later, the
next transaction 700 mysteriously gets dropped.

This is indeed part of why I feel that the xid being skipped should be validated.  As the feature is presented the user is supposed to read the xid from the system (the new stat view or the error log) and supply it and then the worker, when it goes to skip, should find that the very first transaction xid it encounters is the one it is being told to skip.  It skips that transaction, clears the skipxid, and puts the system back into normal operating mode.  If that first transaction xid isn't the one being specified to skip the worker should error with "skipping transaction failed, xid 123 expected but 456 found".

This whole lack of a guarantee of the availability and accuracy regarding the data that this process should be reliant upon needs to be engineered away.

David J.


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

Предыдущее
От: Julien Rouhaud
Дата:
Сообщение: Re: DELETE CASCADE
Следующее
От: Masahiko Sawada
Дата:
Сообщение: Re: Skipping logical replication transactions on subscriber side