Provide PID data for "cannot wait on a latch owned by another process" in latch.c
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t47531psql -h localhost -U postgresBuilt from patchset v1 (message #1), July 28, 2026 at 01:03 AM.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t47531_1 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t47531_1 && git checkout t47531_1Patchset v1 (message #1) is on t47531_1
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 computer programs, 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 computer programs, 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 computer programs, 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