Re: [HACKERS] [BUGS] Bug in Physical Replication Slots (at least9.5)?

Поиск
Список
Период
Сортировка
От Kyotaro HORIGUCHI
Тема Re: [HACKERS] [BUGS] Bug in Physical Replication Slots (at least9.5)?
Дата
Msg-id 20170906.173602.195129146.horiguchi.kyotaro@lab.ntt.co.jp
обсуждение исходный текст
Ответ на Re: [HACKERS] [BUGS] Bug in Physical Replication Slots (at least 9.5)?  (Michael Paquier <michael.paquier@gmail.com>)
Ответы Re: [HACKERS] [BUGS] Bug in Physical Replication Slots (at least9.5)?  (Andres Freund <andres@anarazel.de>)
Список pgsql-hackers
Hi,

At Mon, 4 Sep 2017 17:17:19 +0900, Michael Paquier <michael.paquier@gmail.com> wrote in
<CAB7nPqSPf0qkq=DhSO-tAM9++LSA2aEYSVJ3oY_EdUdb=jKi1w@mail.gmail.com>
> On Mon, Sep 4, 2017 at 4:04 PM, Andres Freund <andres@anarazel.de> wrote:
> > I've not read through the thread, but this seems like the wrong approach
> > to me. The receiving side should use a correct value, instead of putting
> > this complexity on the sender's side.
> 
> Yes I agree with that. The current patch gives me a bad feeling to be
> honest with the way it does things..

The problem is that the current ReadRecord needs the first one of
a series of continuation records from the same source with the
other part, the master in the case.

A (or the) solution closed in the standby side is allowing to
read a seris of continuation records from muliple sources. In
this case the first part from the standby's pg_wal and the second
part from the master via streaming replication.  ReadRecord
needed refactoring, (seems to me) breaking the concept of
XLogReader plug-in system to accomplish this behavior.

If it is preferable for you, I'll re-try that. Or hints for other
solutions are also welcome.

Is there any suggestions?

regards,

-- 
Kyotaro Horiguchi
NTT Open Source Software Center




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

Предыдущее
От: Fabien COELHO
Дата:
Сообщение: Re: [HACKERS] psql - add special variable to reflect the last querystatus
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: [HACKERS] Replacing lfirst() with lfirst_node() appropriately inplanner.c