Re: Provide PID data for "cannot wait on a latch owned by another process" in latch.c
От | Kyotaro Horiguchi |
---|---|
Тема | Re: Provide PID data for "cannot wait on a latch owned by another process" in latch.c |
Дата | |
Msg-id | 20230227.175308.314711483637189642.horikyota.ntt@gmail.com обсуждение исходный текст |
Ответ на | Re: Provide PID data for "cannot wait on a latch owned by another process" in latch.c (Kyotaro Horiguchi <horikyota.ntt@gmail.com>) |
Ответы |
Re: Provide PID data for "cannot wait on a latch owned by another process" in latch.c
|
Список | pgsql-hackers |
Uggg! At Mon, 27 Feb 2023 17:48:10 +0900 (JST), Kyotaro Horiguchi <horikyota.ntt@gmail.com> wrote in > At Mon, 27 Feb 2023 09:20:39 +0900, Michael Paquier <michael@paquier.xyz> wrote in > > Hi all, > > > > While doing something I should not have done, I have been able to > > trigger latch.c with the error of $subject. Adding in the elog > > generated some information about the PID owning the latch and > > MyProcPid has made me understand immediately why I was wrong. Would > > there be any objections to add more information in this case? > > > > The attached patch does so. > > Thanks, > > Please tidy up the followging sentence properly and natural but in a moderately formal way, within the context of computerprograms, and provide explanations for the individual changes you made. Please ignore the following sentense. It is an extra sentence mistakenly copy-pasted in. > +1 for adding that information, I'm afraid that MyProcId is not > necessary since it is displayed in log lines in most cases. If you > want to display the both PIDs I suggest making them more distinctive. regards. -- Kyotaro Horiguchi NTT Open Source Software Center
В списке pgsql-hackers по дате отправления: