Re: Error "initial slot snapshot too large" in create replication slot

Поиск
Список
Период
Сортировка
От Kyotaro Horiguchi
Тема Re: Error "initial slot snapshot too large" in create replication slot
Дата
Msg-id 20220913.161059.331955937797746838.horikyota.ntt@gmail.com
обсуждение исходный текст
Ответ на Re: Error "initial slot snapshot too large" in create replication slot  (Dilip Kumar <dilipbalaut@gmail.com>)
Ответы Re: Error "initial slot snapshot too large" in create replication slot
Список pgsql-hackers
At Tue, 13 Sep 2022 12:08:18 +0530, Dilip Kumar <dilipbalaut@gmail.com> wrote in 
> On Tue, Sep 13, 2022 at 11:52 AM Kyotaro Horiguchi
> <horikyota.ntt@gmail.com> wrote:
> > That function is called after the SnapBuild reaches
> > SNAPBUILD_CONSISTENT state ,or SnapBuildInitialSnapshot() rejects
> > other than that state. That is, IIUC the top-sub relationship of all
> > the currently running transactions is fully known to reorder buffer.
> > We need a comment about that.
> 
> I don't think this assumption is true, any xid started after switching
> to the SNAPBUILD_FULL_SNAPSHOT and before switching to the
> SNAPBUILD_CONSISTENT, might still be in progress so we can not
> identify whether they are subxact or not from reorder buffer.

Yeah, I misunderstood that the relationship is recorded earlier
(how?).  Thus it is not reliable in the first place.

I agree that the best way is oversized xip. 


By the way, I feel that "is >= than" is redundant or plain wrong..

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center



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

Предыдущее
От: Richard Guo
Дата:
Сообщение: Do we need to pass down nonnullable_vars when reducing outer joins?
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: pg_basebackup's --gzip switch misbehaves