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 | CAB7nPqSaWrJD0fVN4uX=e=D9FqEYqPq-S2X_TC60kJ0YX2-5eQ@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 least 9.5)?
|
Список | pgsql-hackers |
On Thu, Oct 26, 2017 at 3:05 AM, Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp> wrote: > The largest obstacle to do that is that walreceiver is not > utterly concerned to record internals. In other words, it doesn't > know what a record is. Teaching that introduces much complexity > and the complexity slows down the walreceiver. > > Addition to that, this "problem" occurs also on replication > without a slot. The latest patch also help the case. That's why replication slots have been introduced to begin with. The WAL receiver gives no guarantee that a segment will be retained or not based on the beginning of a record. That's sad that the WAL receiver does not track properly restart LSN and instead just uses the flush LSN. I am beginning to think that a new message type used to report the restart LSN when a replication slot is in use would just be a better and more stable solution. I haven't looked at the implementation details yet though. -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
В списке pgsql-hackers по дате отправления: