Re: repeated decoding of prepared transactions

Поиск
Список
Период
Сортировка
От Amit Kapila
Тема Re: repeated decoding of prepared transactions
Дата
Msg-id CAA4eK1J_ga6zW6BzQtiwEX-1KZMz-YeoEg0Yd3+1hie136mEwQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: repeated decoding of prepared transactions  (Andres Freund <andres@anarazel.de>)
Список pgsql-hackers
On Sat, Feb 13, 2021 at 10:23 PM Andres Freund <andres@anarazel.de> wrote:
>
> On 2021-02-13 17:37:29 +0100, Petr Jelinek wrote:
>
> > AFAIK this is exactly why origins are Wal logged along with
> > transaction, it allows us to guarantee never getting anything that has
> > beed durably written.
>
> I think you'd need something like origins in that case, because
> something could still go wrong before the other side has received the
> flush (network disconnect, primary crash, ...).
>

We are already using origins in apply-worker to guarantee that and
with each commit, the origin's lsn location is also WAL-logged. That
helps us to send the start location for a slot after the restart. As
far as I understand this is how it works from the apply-worker side. I
am not sure if I am missing something here?

-- 
With Regards,
Amit Kapila.



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

Предыдущее
От: Thomas Munro
Дата:
Сообщение: Re: Default wal_sync_method on FreeBSD
Следующее
От: Peter Geoghegan
Дата:
Сообщение: Re: 64-bit XIDs in deleted nbtree pages