Обсуждение: Provide PID data for "cannot wait on a latch owned by another process" in latch.c

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

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

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

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

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

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?

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