Re: Diagnostic comment in LogicalIncreaseXminForSlot
От | Amit Kapila |
---|---|
Тема | Re: Diagnostic comment in LogicalIncreaseXminForSlot |
Дата | |
Msg-id | CAA4eK1+UnNNw_o=dM0m+sLKo4ePOOc+Lb7p_iN7GhuEQdZH2-A@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Diagnostic comment in LogicalIncreaseXminForSlot (Masahiko Sawada <sawada.mshk@gmail.com>) |
Ответы |
Re: Diagnostic comment in LogicalIncreaseXminForSlot
|
Список | pgsql-hackers |
On Mon, Jul 5, 2021 at 12:54 PM Masahiko Sawada <sawada.mshk@gmail.com> wrote: > > On Fri, May 21, 2021 at 6:00 PM Ashutosh Bapat > <ashutosh.bapat@enterprisedb.com> wrote: > > > > It's there in CF. I am fine with PG-15. It will be good to patch the back-branches to have this extra diagnostic informationavailable. > > The patch looks to me. > { slot->candidate_catalog_xmin = xmin; slot->candidate_xmin_lsn = current_lsn; + elog(DEBUG1, "got new catalog_xmin %u at %X/%X", xmin, + LSN_FORMAT_ARGS(current_lsn)); } SpinLockRelease(&slot->mutex); Today, again looking at this patch, I don't think doing elog inside spinlock is a good idea. We can either release spinlock before it or use some variable to remember that we need to write such an elog and do it after releasing the lock. What do you think? I have noticed that a nearby function LogicalIncreaseRestartDecodingForSlot() logs similar information after releasing spinlock, so it is better to follow the same here as well. -- With Regards, Amit Kapila.
В списке pgsql-hackers по дате отправления: