Re: [HACKERS] [BUGS] Bug in Physical Replication Slots (at least 9.5)?
От | Michael Paquier |
---|---|
Тема | Re: [HACKERS] [BUGS] Bug in Physical Replication Slots (at least 9.5)? |
Дата | |
Msg-id | CAB7nPqT03+uaHXun3ft4LJWNDviKTgWSZDsXiqyNdtcCfeqcgg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] [BUGS] Bug in Physical Replication Slots (at least9.5)? (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>) |
Ответы |
Re: [HACKERS] [BUGS] Bug in Physical Replication Slots (at least9.5)?
|
Список | pgsql-hackers |
On Mon, Aug 28, 2017 at 8:02 PM, Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp> wrote: > The first patch (0001-) fixes this problem, preventing the > problematic state of WAL segments by retarding restart LSN of a > physical replication slot in a certain condition. FWIW, I have this patch marked on my list of things to look at, so you can count me as a reviewer. There are also some approaches that I would like to test because I rely on replication slots for some infrastructure. Still... + if (oldFlushPtr != InvalidXLogRecPtr && + (restartLSN == InvalidXLogRecPtr ? + oldFlushPtr / XLOG_SEG_SIZE != flushPtr / XLOG_SEG_SIZE : + restartLSN / XLOG_BLCKSZ != flushPtr / XLOG_BLCKSZ)) I find such code patterns not readable. -- Michael
В списке pgsql-hackers по дате отправления: