Re: Synchronizing slots from primary to standby
От | Amit Kapila |
---|---|
Тема | Re: Synchronizing slots from primary to standby |
Дата | |
Msg-id | CAA4eK1+LL8q2cy5EJb1OLRmQi_m-F+vzS_mXhR=PsbvhbKXmtw@mail.gmail.com обсуждение исходный текст |
Ответ на | RE: Synchronizing slots from primary to standby ("Zhijie Hou (Fujitsu)" <houzj.fnst@fujitsu.com>) |
Ответы |
Re: Synchronizing slots from primary to standby
|
Список | pgsql-hackers |
On Fri, Feb 16, 2024 at 11:12 AM Zhijie Hou (Fujitsu) <houzj.fnst@fujitsu.com> wrote: > > On Friday, February 16, 2024 8:33 AM Zhijie Hou (Fujitsu) <houzj.fnst@fujitsu.com> wrote: > > > > > > Yeah, we can consider outputting some information via this function > > > like how many slots are synced and persisted but not sure what would > > > be appropriate here. Because one can anyway find that or more > > > information by querying pg_replication_slots. I think we can keep > > > discussing what makes more sense as a return value but let's commit > > > the debug/log patches as they will be helpful to analyze BF failures or any > > other issues reported. > > > > Agreed. Here is new patch set as suggested. I used debug2 in the 040 as it could > > provide more information about communication between primary and standby. > > This also doesn't increase noticeable testing time on my machine for debug > > build. > > Sorry, there was a miss in the DEBUG message, I should have used > UINT64_FORMAT for XLogSegNo(uint64) instead of %ld. Here is a small patch > to fix this. > Thanks for noticing this. I have pushed all your debug patches. Let's hope if there is a BF failure next time, we can gather enough information to know the reason of the same. -- With Regards, Amit Kapila.
В списке pgsql-hackers по дате отправления: