WAL recycled despite logical replication slot

Поиск
Список
Период
Сортировка
От Jeff Janes
Тема WAL recycled despite logical replication slot
Дата
Msg-id CAMkU=1yR2V_2F2is+XTPqe6oLruXKgPmYkGS7m1dUunMKnrFRg@mail.gmail.com
обсуждение исходный текст
Ответы Re: WAL recycled despite logical replication slot  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
Re: WAL recycled despite logical replication slot  (Andres Freund <andres@anarazel.de>)
Список pgsql-hackers

While testing something else (whether "terminating walsender process due to replication timeout" was happening spuriously), I had logical replication set up streaming a default pgbench transaction load, with the publisher being 13devel-e1c8743 and subscriber being 12BETA4.  Eventually I started getting errors about requested wal segments being already removed:

10863 sub idle 00000 2019-09-19 17:14:58.140 EDT LOG:  starting logical decoding for slot "sub"
10863 sub idle 00000 2019-09-19 17:14:58.140 EDT DETAIL:  Streaming transactions committing after 79/EB0B17A0, reading WAL from 79/E70736A0.
10863 sub idle 58P01 2019-09-19 17:14:58.140 EDT ERROR:  requested WAL segment 0000000100000079000000E7 has already been removed
10863 sub idle 00000 2019-09-19 17:14:58.144 EDT LOG:  disconnection: session time: 0:00:00.030 user=jjanes database=jjanes host=10.0.2.2 port=40830

It had been streaming for about 50 minutes before the error showed up, and it showed right when streaming was restarting after one of the replication timeouts.

Is there an innocent explanation for this?  I thought logical replication slots provided an iron-clad guarantee that WAL would be retained until it was no longer needed.  I am just using pub/sub, none of the lower level stuff.

Cheers,

Jeff

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

Предыдущее
От: Asim R P
Дата:
Сообщение: Re: standby recovery fails (tablespace related) (tentative patch and discussion)
Следующее
От: Robert Haas
Дата:
Сообщение: Re: backup manifests