Re: Reviving lost replication slots
| От | Bharath Rupireddy |
|---|---|
| Тема | Re: Reviving lost replication slots |
| Дата | |
| Msg-id | CALj2ACWK=QL37m=3x4UEtyURzOaLADh6QZEq120i6OCaeRFkAQ@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Reviving lost replication slots (Amit Kapila <amit.kapila16@gmail.com>) |
| Список | pgsql-hackers |
On Wed, Nov 9, 2022 at 3:53 PM Amit Kapila <amit.kapila16@gmail.com> wrote: > > On Wed, Nov 9, 2022 at 3:00 PM Bharath Rupireddy > <bharath.rupireddyforpostgres@gmail.com> wrote: > > > > On Wed, Nov 9, 2022 at 2:02 PM Kyotaro Horiguchi > > <horikyota.ntt@gmail.com> wrote: > > > > > > I don't think walsenders fetching segment from archive is totally > > > stupid. With that feature, we can use fast and expensive but small > > > storage for pg_wal, while avoiding replciation from dying even in > > > emergency. > > > > It seems like a useful feature to have at least as an option and it > > saves a lot of work - failovers, expensive rebuilds of > > standbys/subscribers, manual interventions etc. > > > > If you're saying that even the walsedners serving logical replication > > subscribers would go fetch from the archive location for the removed > > WAL files, it mandates enabling archiving on the subscribers. > > > > Why archiving on subscribers is required? Won't it be sufficient if > that is enabled on the publisher where we have walsender? Ugh. A typo. I meant it mandates enabling archiving on publishers. -- Bharath Rupireddy PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com
В списке pgsql-hackers по дате отправления: