Re: [HACKERS] Restricting maximum keep segments by repslots
От | Craig Ringer |
---|---|
Тема | Re: [HACKERS] Restricting maximum keep segments by repslots |
Дата | |
Msg-id | CAMsr+YFa2TvmM+ZNWME3W9jOgAxOyu7OByQV8tsL1XbUM=Fwcw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] Restricting maximum keep segments by repslots (Petr Jelinek <petr.jelinek@2ndquadrant.com>) |
Список | pgsql-hackers |
On 28 February 2017 at 12:27, Petr Jelinek <petr.jelinek@2ndquadrant.com> wrote: >> This patch adds a GUC to put a limit to the number of segments >> that replication slots can keep. Hitting the limit during >> checkpoint shows a warining and the segments older than the limit >> are removed. >> >>> WARNING: restart LSN of replication slots is ignored by checkpoint >>> DETAIL: Some replication slots lose required WAL segnents to continue. >> > > However this is dangerous as logical replication slot does not consider > it error when too old LSN is requested so we'd continue replication, > hiding data loss. That skipping only happens if you request a startpoint older than confirmed_flush_lsn . It doesn't apply to this situation. The client cannot control where we start decoding, it's always restart_lsn, and if we can't find a needed WAL segment we'll ERROR. So this is safe, though the error will be something about being unable to find a wal segment that users might not directly associate with having set this option. It won't say "slot disabled because needed WAL has been discarded due to [setting]" or anything. -- Craig Ringer http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: