public inbox for [email protected]
help / color / mirror / Atom feed[PATCH v5 2/2] Include the leader PID in logfile
10+ messages / 5 participants
[nested] [flat]
* [PATCH v5 2/2] Include the leader PID in logfile
@ 2020-03-14 03:03 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 10+ messages in thread
From: Justin Pryzby @ 2020-03-14 03:03 UTC (permalink / raw)
See also: b025f32e0b, which added the leader PID to pg_stat_activity
---
doc/src/sgml/config.sgml | 10 ++++++-
src/backend/utils/error/elog.c | 29 +++++++++++++++++++
src/backend/utils/misc/postgresql.conf.sample | 1 +
3 files changed, 39 insertions(+), 1 deletion(-)
diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
index 994155ca00..e1da2e12e8 100644
--- a/doc/src/sgml/config.sgml
+++ b/doc/src/sgml/config.sgml
@@ -6694,6 +6694,13 @@ local0.* /var/log/postgresql
<entry>Process ID</entry>
<entry>no</entry>
</row>
+ <row>
+ <entry><literal>%P</literal></entry>
+ <entry>Process ID of the parallel group leader, if this process is
+ a parallel query worker.
+ </entry>
+ <entry>no</entry>
+ </row>
<row>
<entry><literal>%t</literal></entry>
<entry>Time stamp without milliseconds</entry>
@@ -7026,7 +7033,7 @@ log_line_prefix = '%m [%p] %q%u@%d/%a '
character count of the error position therein,
location of the error in the PostgreSQL source code
(if <varname>log_error_verbosity</varname> is set to <literal>verbose</literal>),
- application name, and backend type.
+ application name, backend type, and leader PID.
Here is a sample table definition for storing CSV-format log output:
<programlisting>
@@ -7056,6 +7063,7 @@ CREATE TABLE postgres_log
location text,
application_name text,
backend_type text,
+ leader_pid integer,
PRIMARY KEY (session_id, session_line_num)
);
</programlisting>
diff --git a/src/backend/utils/error/elog.c b/src/backend/utils/error/elog.c
index b0b1a09ab1..60e2f524a7 100644
--- a/src/backend/utils/error/elog.c
+++ b/src/backend/utils/error/elog.c
@@ -77,6 +77,7 @@
#include "postmaster/syslogger.h"
#include "storage/ipc.h"
#include "storage/proc.h"
+#include "storage/procarray.h"
#include "tcop/tcopprot.h"
#include "utils/guc.h"
#include "utils/memutils.h"
@@ -2425,6 +2426,23 @@ log_line_prefix(StringInfo buf, ErrorData *edata)
case 'p':
appendStringInfo(buf, "%*d", padding, MyProcPid);
break;
+
+ case 'P':
+ if (MyProc)
+ {
+ PGPROC *leader = MyProc->lockGroupLeader;
+ if (leader != NULL && leader->pid != MyProcPid)
+ /* leader_pid is blank for the leader itself */
+ appendStringInfo(buf, "%*d", padding, leader->pid);
+ else
+ appendStringInfoSpaces(buf,
+ padding > 0 ? padding : -padding);
+ }
+ else if (padding != 0)
+ appendStringInfoSpaces(buf,
+ padding > 0 ? padding : -padding);
+ break;
+
case 'l':
appendStringInfo(buf, "%*ld", padding, log_line_number);
break;
@@ -2766,6 +2784,17 @@ write_csvlog(ErrorData *edata)
else
appendCSVLiteral(&buf, GetBackendTypeDesc(MyBackendType));
+ appendStringInfoChar(&buf, ',');
+
+ /* leader PID */
+ if (MyProc)
+ {
+ PGPROC *leader = MyProc->lockGroupLeader;
+ /* leader_pid is blank for leader itself */
+ if (leader && leader->pid != MyProcPid)
+ appendStringInfo(&buf, "%d", leader->pid);
+ }
+
appendStringInfoChar(&buf, '\n');
/* If in the syslogger process, try to write messages direct to file */
diff --git a/src/backend/utils/misc/postgresql.conf.sample b/src/backend/utils/misc/postgresql.conf.sample
index b0715ae188..1ecdfc51a6 100644
--- a/src/backend/utils/misc/postgresql.conf.sample
+++ b/src/backend/utils/misc/postgresql.conf.sample
@@ -537,6 +537,7 @@
# %h = remote host
# %b = backend type
# %p = process ID
+ # %P = leader PID
# %t = timestamp without milliseconds
# %m = timestamp with milliseconds
# %n = timestamp with milliseconds (as a Unix epoch)
--
2.17.0
--fDERRRNgB4on1jOB--
^ permalink raw reply [nested|flat] 10+ messages in thread
* lwlocknames.h beautification attempt
@ 2025-03-02 06:09 Gurjeet Singh <[email protected]>
0 siblings, 1 reply; 10+ messages in thread
From: Gurjeet Singh @ 2025-03-02 06:09 UTC (permalink / raw)
To: pgsql-hackers
Currently the contents of lwlocknames.h look like this:
#define ShmemIndexLock (&MainLWLockArray[1].lock)
#define OidGenLock (&MainLWLockArray[2].lock)
#define XidGenLock (&MainLWLockArray[3].lock)
#define ProcArrayLock (&MainLWLockArray[4].lock)
#define SInvalReadLock (&MainLWLockArray[5].lock)
...
This makes it a bit hard to read, since there is no attempt at vertical
alignment along the opening parentheses. It gets worse if the editor
performs syntax highlighting, and the various colored characters in the
definitions appear haphazardly arranged.
Had this been hand-written, I can imagine the author making an attempt at
aligning the definitions, but since this is a generated file, the lack of
that attempt is understandable.
I propose the following change to the generation script,
generate-lwlocknames.pl
- print $h "#define ${lockname}Lock (&MainLWLockArray[$lockidx].lock)\n";
+ printf $h "#define %-30s %s\n", "${lockname}Lock",
"(&MainLWLockArray[$lockidx].lock)";
which produces the lock names in this format
#define ShmemIndexLock (&MainLWLockArray[1].lock)
#define OidGenLock (&MainLWLockArray[2].lock)
#define XidGenLock (&MainLWLockArray[3].lock)
#define ProcArrayLock (&MainLWLockArray[4].lock)
#define SInvalReadLock (&MainLWLockArray[5].lock)
...
Yet another format, which I prefer, can be achieved by right-aligning the
lock names. In addition to aligning the definitions, it also aligns the
'Lock' suffix in all the names. But as they say beauty is in the eye of the
beholder, so this one may be actively disliked by others.
- print $h "#define ${lockname}Lock (&MainLWLockArray[$lockidx].lock)\n";
+ printf $h "#define %30s %s\n", "${lockname}Lock",
"(&MainLWLockArray[$lockidx].lock)";
#define ShmemIndexLock (&MainLWLockArray[1].lock)
#define OidGenLock (&MainLWLockArray[2].lock)
#define XidGenLock (&MainLWLockArray[3].lock)
#define ProcArrayLock (&MainLWLockArray[4].lock)
#define SInvalReadLock (&MainLWLockArray[5].lock)
...
The lockname column needs to be at least 30 chars wide to accommodate the
longest of the lock names 'DynamicSharedMemoryControlLock'.
Best regards,
Gurjeet
http://Gurje.et
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: lwlocknames.h beautification attempt
@ 2025-03-14 19:38 Álvaro Herrera <[email protected]>
parent: Gurjeet Singh <[email protected]>
0 siblings, 1 reply; 10+ messages in thread
From: Álvaro Herrera @ 2025-03-14 19:38 UTC (permalink / raw)
To: Gurjeet Singh <[email protected]>; +Cc: pgsql-hackers
On 2025-Mar-01, Gurjeet Singh wrote:
> I propose the following change to the generation script,
> generate-lwlocknames.pl
>
> - print $h "#define ${lockname}Lock (&MainLWLockArray[$lockidx].lock)\n";
> + printf $h "#define %-30s %s\n", "${lockname}Lock",
> "(&MainLWLockArray[$lockidx].lock)";
I forgot to send a note here that I pushed this patch. Thank you.
--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
[…] indem ich in meinem Leben oft an euch gedacht, euch glücklich zu machen. Seyd es!
A menudo he pensado en vosotros, en haceros felices. ¡Sedlo, pues!
Heiligenstädter Testament, L. v. Beethoven, 1802
https://de.wikisource.org/wiki/Heiligenstädter_Testament
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: lwlocknames.h beautification attempt
@ 2025-03-17 02:53 Robert Haas <[email protected]>
parent: Álvaro Herrera <[email protected]>
0 siblings, 2 replies; 10+ messages in thread
From: Robert Haas @ 2025-03-17 02:53 UTC (permalink / raw)
To: Álvaro Herrera <[email protected]>; +Cc: Gurjeet Singh <[email protected]>; pgsql-hackers
On Fri, Mar 14, 2025 at 3:38 PM Álvaro Herrera <[email protected]> wrote:
> I forgot to send a note here that I pushed this patch. Thank you.
I'm confused. Tom and I both said we didn't like this change, so you
committed the patch without further discussion?
I mean, this is a pretty unimportant detail, so I don't really want to
fight about it too much, but that really doesn't seem like a consensus
to me.
--
Robert Haas
EDB: http://www.enterprisedb.com
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: lwlocknames.h beautification attempt
@ 2025-03-17 06:43 Álvaro Herrera <[email protected]>
parent: Robert Haas <[email protected]>
1 sibling, 1 reply; 10+ messages in thread
From: Álvaro Herrera @ 2025-03-17 06:43 UTC (permalink / raw)
To: Robert Haas <[email protected]>; +Cc: Gurjeet Singh <[email protected]>; pgsql-hackers
On 2025-Mar-16, Robert Haas wrote:
> On Fri, Mar 14, 2025 at 3:38 PM Álvaro Herrera <[email protected]> wrote:
> > I forgot to send a note here that I pushed this patch. Thank you.
>
> I'm confused. Tom and I both said we didn't like this change, so you
> committed the patch without further discussion?
Tom didn't say he didn't like this change. He said he didn't like a
different change, which is not the one I committed. And your opinion
was quite thin on arguments, and you didn't reply for 11 days after I
expressed intention to apply a simplified version of Gurjeet's patch.
> I mean, this is a pretty unimportant detail, so I don't really want to
> fight about it too much, but that really doesn't seem like a consensus
> to me.
Would you have objected if I had proposed to use that style to begin with?
You can see that the thread where this was discussed [1] was pretty
light on coding style/output style discussion. It seems hard to argue
that the original had achieved any kind of consensus.
[1] https://postgr.es/m/[email protected]
--
Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/
^ permalink raw reply [nested|flat] 10+ messages in thread
* Fwd: lwlocknames.h beautification attempt
@ 2025-03-17 06:44 Gurjeet Singh <[email protected]>
parent: Robert Haas <[email protected]>
1 sibling, 2 replies; 10+ messages in thread
From: Gurjeet Singh @ 2025-03-17 06:44 UTC (permalink / raw)
To: Robert Haas <[email protected]>; +Cc: Álvaro Herrera <[email protected]>; pgsql-hackers
(resending the email because it was held for moderation; replaced image
attachment with a link, which might be the reason for being put in the
moderation queue)
On Sun, Mar 16, 2025 at 7:53 PM Robert Haas <[email protected]> wrote:
>
> On Fri, Mar 14, 2025 at 3:38 PM Álvaro Herrera <[email protected]> wrote:
> > I forgot to send a note here that I pushed this patch. Thank you.
>
> I'm confused. Tom and I both said we didn't like this change,
To me, Tom's feedback felt as being between ambivalent to the change and perhaps
agree with the change, as long as pgindent did not throw a fit, which
it did not.
It definitely did not feel like a -1.
On Mon, Mar 3, 2025 at 8:40 AM Robert Haas <[email protected]> wrote:
>
> On Sun, Mar 2, 2025 at 1:10 AM Gurjeet Singh <[email protected]> wrote:
> > I propose the following change to the generation script, generate-lwlocknames.pl
> >
> > - print $h "#define ${lockname}Lock (&MainLWLockArray[$lockidx].lock)\n";
> > + printf $h "#define %-30s %s\n", "${lockname}Lock", "(&MainLWLockArray[$lockidx].lock)";
>
> -1. That seems worse to me.
I read your objection to be about the perl code change, whereas the real change
the patch was seeking is in the generated output (lwlocknames.h). I'm guessing
some others may also have taken your feedback to mean the same as I did.
Alvaro committed the following patch, which is better code than mine. If your
objection was about the perl code, perhaps this addresses your concern.
- print $h "#define ${lockname}Lock (&MainLWLockArray[$lockidx].lock)\n";
+ printf $h "#define %-32s (&MainLWLockArray[$lockidx].lock)\n",
+ $lockname . "Lock";
I have ~attached~ linked a comparison of before and after screenshots of the
generated output. It's hard to argue that the generated code in the left/before
image is better than the right/after image.
https://photos.app.goo.gl/hNL3FaUMuEwnaYTt9
Best regards,
Gurjeet
http://Gurje.et
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: Fwd: lwlocknames.h beautification attempt
@ 2025-03-17 06:58 Tom Lane <[email protected]>
parent: Gurjeet Singh <[email protected]>
1 sibling, 0 replies; 10+ messages in thread
From: Tom Lane @ 2025-03-17 06:58 UTC (permalink / raw)
To: Gurjeet Singh <[email protected]>; +Cc: Robert Haas <[email protected]>; Álvaro Herrera <[email protected]>; pgsql-hackers
Gurjeet Singh <[email protected]> writes:
> On Sun, Mar 16, 2025 at 7:53 PM Robert Haas <[email protected]> wrote:
>> I'm confused. Tom and I both said we didn't like this change,
> To me, Tom's feedback felt as being between ambivalent to the change and perhaps
> agree with the change, as long as pgindent did not throw a fit, which
> it did not.
Geez, are we really going to argue about whitespace in a generated
file? But anyway, what I said was that I didn't like the style with
the define'd symbol right-justified, because it didn't look like
anything else in our code. I'm entirely okay with the committed
version, which has plenty of precedent formatting-wise.
regards, tom lane
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: Fwd: lwlocknames.h beautification attempt
@ 2025-03-17 08:20 Álvaro Herrera <[email protected]>
parent: Gurjeet Singh <[email protected]>
1 sibling, 0 replies; 10+ messages in thread
From: Álvaro Herrera @ 2025-03-17 08:20 UTC (permalink / raw)
To: Gurjeet Singh <[email protected]>; +Cc: Robert Haas <[email protected]>; pgsql-hackers
On 2025-Mar-16, Gurjeet Singh wrote:
> (resending the email because it was held for moderation; replaced image
> attachment with a link, which might be the reason for being put in the
> moderation queue)
Kindly don't do this (specifically: cancel the original message and send
a different copy). Just have patience with the moderation queue.
Messages are typically approved within a day anyway.
--
Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: lwlocknames.h beautification attempt
@ 2025-03-17 13:10 Robert Haas <[email protected]>
parent: Álvaro Herrera <[email protected]>
0 siblings, 1 reply; 10+ messages in thread
From: Robert Haas @ 2025-03-17 13:10 UTC (permalink / raw)
To: Álvaro Herrera <[email protected]>; +Cc: Gurjeet Singh <[email protected]>; pgsql-hackers
On Mon, Mar 17, 2025 at 2:43 AM Álvaro Herrera <[email protected]> wrote:
> Tom didn't say he didn't like this change. He said he didn't like a
> different change, which is not the one I committed.
Sorry, I should have read the emails more carefully. I missed the fact
that there were two different proposals. It was the idea of
right-aligning things that I was unhappy about.
So, no objection to what you actually committed... except that I don't
think that using % specifiers in SOME places in a format string is
better than using them in ALL the places. It's not broken because
$lockidx can't contain a % sign, but in general I think when we switch
from print to printf it's better for us to have the format string be a
constant so that it's clear that we can't accidentally get an extra %
escape in there depending on the values of variables being
interpolated.
--
Robert Haas
EDB: http://www.enterprisedb.com
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: lwlocknames.h beautification attempt
@ 2025-03-17 15:38 Álvaro Herrera <[email protected]>
parent: Robert Haas <[email protected]>
0 siblings, 0 replies; 10+ messages in thread
From: Álvaro Herrera @ 2025-03-17 15:38 UTC (permalink / raw)
To: Robert Haas <[email protected]>; +Cc: Gurjeet Singh <[email protected]>; pgsql-hackers
On 2025-Mar-17, Robert Haas wrote:
> On Mon, Mar 17, 2025 at 2:43 AM Álvaro Herrera <[email protected]> wrote:
> > Tom didn't say he didn't like this change. He said he didn't like a
> > different change, which is not the one I committed.
>
> Sorry, I should have read the emails more carefully. I missed the fact
> that there were two different proposals. It was the idea of
> right-aligning things that I was unhappy about.
Ah, okay.
> So, no objection to what you actually committed... except that I don't
> think that using % specifiers in SOME places in a format string is
> better than using them in ALL the places. It's not broken because
> $lockidx can't contain a % sign, but in general I think when we switch
> from print to printf it's better for us to have the format string be a
> constant so that it's clear that we can't accidentally get an extra %
> escape in there depending on the values of variables being
> interpolated.
I suppose this is a reasonable complaint; however, I don't see an actual
problem here. Even if I hack the regexp in generate-lwlocknames.pl to
accept a %-sign in the lock name (and introduce a matching % in
wait_event_names.txt), then that % is emitted verbatim rather than
attempted to further expand. Is this because this is Perl rather than
C? I'm not sure.
Note that a % in the lock number (which also needs a regexp hack) can't
cause a problem either, because of the check that the lock numbers are
an ordered sequence.
I think it's quite difficult to cause actual problems here.
--
Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/
^ permalink raw reply [nested|flat] 10+ messages in thread
end of thread, other threads:[~2025-03-17 15:38 UTC | newest]
Thread overview: 10+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2020-03-14 03:03 [PATCH v5 2/2] Include the leader PID in logfile Justin Pryzby <[email protected]>
2025-03-02 06:09 lwlocknames.h beautification attempt Gurjeet Singh <[email protected]>
2025-03-14 19:38 ` Re: lwlocknames.h beautification attempt Álvaro Herrera <[email protected]>
2025-03-17 02:53 ` Re: lwlocknames.h beautification attempt Robert Haas <[email protected]>
2025-03-17 06:43 ` Re: lwlocknames.h beautification attempt Álvaro Herrera <[email protected]>
2025-03-17 13:10 ` Re: lwlocknames.h beautification attempt Robert Haas <[email protected]>
2025-03-17 15:38 ` Re: lwlocknames.h beautification attempt Álvaro Herrera <[email protected]>
2025-03-17 06:44 ` Fwd: lwlocknames.h beautification attempt Gurjeet Singh <[email protected]>
2025-03-17 06:58 ` Re: Fwd: lwlocknames.h beautification attempt Tom Lane <[email protected]>
2025-03-17 08:20 ` Re: Fwd: lwlocknames.h beautification attempt Álvaro Herrera <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox