Thread: Provide PID data for "cannot wait on a latch owned by another process" in latch.c
Provide PID data for "cannot wait on a latch owned by another process" in latch.c
From
Michael Paquier
Date:
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, -- Michael
Attachment
Re: Provide PID data for "cannot wait on a latch owned by another process" in latch.c
From
Kyotaro Horiguchi
Date:
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. +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
Re: Provide PID data for "cannot wait on a latch owned by another process" in latch.c
From
Kyotaro Horiguchi
Date:
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
Re: Provide PID data for "cannot wait on a latch owned by another process" in latch.c
From
Kyotaro Horiguchi
Date:
Uggg^2 At Mon, 27 Feb 2023 17:53:08 +0900 (JST), Kyotaro Horiguchi <horikyota.ntt@gmail.com> wrote in > > 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 s/following/above/; > 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
Re: Provide PID data for "cannot wait on a latch owned by another process" in latch.c
From
Michael Paquier
Date:
On Mon, Feb 27, 2023 at 05:48:10PM +0900, Kyotaro Horiguchi wrote: > +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. What would you suggest? This message is basically impossible to reach so the wording of the patch was OK for me (see async.c) so you would need to look at the internals anyway. Now if you'd like something like "could not blah: owner PID=%d, MyProcPid=%d", that's also fine by me. -- Michael
Attachment
Re: Provide PID data for "cannot wait on a latch owned by another process" in latch.c
From
Peter Eisentraut
Date:
On 28.02.23 00:59, Michael Paquier wrote: > On Mon, Feb 27, 2023 at 05:48:10PM +0900, Kyotaro Horiguchi wrote: >> +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. > > What would you suggest? This message is basically impossible to > reach so the wording of the patch was OK for me (see async.c) so you > would need to look at the internals anyway. Now if you'd like > something like "could not blah: owner PID=%d, MyProcPid=%d", that's > also fine by me. I would also have asked for some kind of prefix that introduces the numbers. I wonder what these numbers are useful for though? Is this a development aid? Can you do anything with these numbers?
Re: Provide PID data for "cannot wait on a latch owned by another process" in latch.c
From
Michael Paquier
Date:
On Tue, Feb 28, 2023 at 08:18:16AM +0100, Peter Eisentraut wrote: > I would also have asked for some kind of prefix that introduces the numbers. Okay. > I wonder what these numbers are useful for though? Is this a development > aid? Yes. > Can you do anything with these numbers? Yes. They immediately pointed out that I missed to mark a latch as owned in a process, hence the owner_pid was showing up as 0 when trying to use it. The second showed me the process that was involved, which was still useful once cross-checked with the contents of the logs prefixed with %p. -- Michael