Re: Time delayed LR (WAS Re: logical replication restrictions)
От | Amit Kapila |
---|---|
Тема | Re: Time delayed LR (WAS Re: logical replication restrictions) |
Дата | |
Msg-id | CAA4eK1JPxAX3__Cy-oD+bH3arYU0Jdn_ihRPJOF8hdjWChfKWQ@mail.gmail.com обсуждение исходный текст |
Ответ на | RE: Time delayed LR (WAS Re: logical replication restrictions) ("Takamichi Osumi (Fujitsu)" <osumi.takamichi@fujitsu.com>) |
Ответы |
Re: Time delayed LR (WAS Re: logical replication restrictions)
|
Список | pgsql-hackers |
On Fri, Feb 10, 2023 at 4:56 PM Takamichi Osumi (Fujitsu) <osumi.takamichi@fujitsu.com> wrote: > > On Friday, February 10, 2023 2:05 PM Friday, February 10, 2023 2:05 PM wrote: > > On Fri, Feb 10, 2023 at 10:11 AM Amit Kapila <amit.kapila16@gmail.com> > > wrote: > > In the previous patch, we couldn't solve the > timeout of the publisher, when we conduct a scenario suggested by Horiguchi-san > and reproduced in the scenario attached test file 'test.sh'. > But now we handle it by adjusting the timing of the first wait time. > > FYI, we thought to implement the new variable 'send_time' > in the LogicalRepWorker structure at first. But, this structure > is used when launcher controls workers or reports statistics > and it stores TimestampTz recorded in the received WAL, > so not sure if the struct is the right place to implement the variable. > Moreover, there are other similar variables such as last_recv_time > or reply_time. So, those will be confusing when we decide to have > new variable together. Then, it's declared separately. > I think we can introduce a new variable as last_feedback_time in the LogicalRepWorker structure and probably for the last_received, we can last_lsn in MyLogicalRepWorker as that seems to be updated correctly. I think it would be good to avoid global variables. -- With Regards, Amit Kapila.
В списке pgsql-hackers по дате отправления: