On Mon, Apr 7, 2025 at 11:59 AM Tom Lane wrote:
> Robert Haas writes:
> > The only thing that makes me a little bit sad is that we don't seem to
> > have added this to pg_stat_activity.
>
> Hmm, that seems like it'd be a completely separate discussion.
Yes, not something we should try to squeeze
Robert Haas writes:
> The only thing that makes me a little bit sad is that we don't seem to
> have added this to pg_stat_activity.
Hmm, that seems like it'd be a completely separate discussion.
My main objection to the idea is that if we do that then everybody
will pay the overhead for it, whet
On Sun, Apr 6, 2025 at 8:50 PM Greg Sabino Mullane wrote:
> I lean for #1. Yes, there is some inconsistency, but it feels like the right
> thing to do, and this is a feature I suspect not many people will use anyway.
I just saw the commit message here and thought I would show up to say
that it s
Greg Sabino Mullane writes:
> On Sun, Apr 6, 2025 at 6:01 PM Tom Lane wrote:
>> 1. Ignore the inconsistency, commit 0004 as-is.
>>
>> 2. Change the output to be an empty string in background processes.
>> This is consistent, but it goes against our upthread feeling that
>> "[none]" would avoid c
On Sun, Apr 6, 2025 at 6:01 PM Tom Lane wrote:
> 1. Ignore the inconsistency, commit 0004 as-is.
>
> 2. Change the output to be an empty string in background processes.
>This is consistent, but it goes against our upthread feeling that
> "[none]" would avoid confusion.
>
I lean for #1. Yes,
Michael Paquier writes:
> I'd suggest the addition of this data to csvlog.c and jsonlog.c,
> perhaps only adding this information if local_host[0] is not '\0'
> rather than assigning a default "[none]" all the time to save some
> space in the entries generated.
I think that's completely impractic
On Sun, Apr 06, 2025 at 06:01:01PM -0400, Tom Lane wrote:
> I don't really care for #3 or #4, but I'm ambivalent between #1 and
> #2. I think the worry about confusion originated when the patch
> would print "[local]" for either a Unix socket or a background
> process, and that certainly was confu
Greg Sabino Mullane writes:
> I have not attempted the caching change yet.
After some thought I concluded that caching the local-address string
in MyProcPort itself would be the most robust way of making that work.
Otherwise you need some way to update the cache when MyProcPort is
created (in cas
Jim Jones writes:
> In that case, it LGTM.
I looked at 0002 briefly. I don't have any particular objection to
the proposed feature, but I'm quite concerned about the potential
performance implications of doing a new pg_getnameinfo_all() call
for every line of log output. I think that needs to b
Thanks for all the feedback. Please find attached a version which prints
"[none]" as the default value, "[local]" for a socket, and otherwise
whatever pg_getnameinfo_all spits out. I cleaned up the coding, respected
padding, removed the family checks, and expanded the docs a tiny bit to
give the re
Oh, one other thing: pg_getnameinfo_all is perfectly capable of
dealing with a Unix-socket address, so I think you should drop
the tests on ss_family and let pg_getnameinfo_all be in charge
of producing "[local]" for that case.
regards, tom lane
On 27.02.25 14:54, Greg Sabino Mullane wrote:
> Great question. I think "supposed to" is a bit of a stretch, but I
> presume it's the difference between a client connecting and using its
> connection information versus an already existing backend process,
> which is always going to be "local".
>
On Mon, Nov 18, 2024 at 10:07 AM Jim Jones
wrote:
> 2024-11-18 16:00:42.720 CET [3135117] -> 192.168.178.27 STATEMENT:
> ...
> 2024-11-18 16:01:23.273 CET [3114980] -> [local] LOG: received SIGHUP,
> ...
2024-11-18 16:01:46.769 CET [3114981] -> [local] LOG: checkpoint
> Is it supposed to be li
Hi Greg
On 11.07.24 18:09, Greg Sabino Mullane wrote:
> Thanks for the review. Please find attached a new version with proper
> tabs and indenting.
>
> Cheers,
> Greg
>
I'm testing this new log prefix and I'm wondering whether the following
behaviour is expected. The value of '%L' is different in
On 7/11/24 23:09, Greg Sabino Mullane wrote:
Thanks for the review. Please find attached a new version with proper
tabs and indenting.
This looks good to me now. +1 overall for the feature.
Regards,
-David
Thanks for the review. Please find attached a new version with proper tabs
and indenting.
Cheers,
Greg
0002-Add-local-address-to-log_line_prefix.patch
Description: Binary data
On 5/24/24 22:33, Greg Sabino Mullane wrote:
Peter, thank you for the feedback. Attached is a new patch with
"address" rather than "interface", plus a new default of "local" if
there is no address. I also removed the questionable comment, and
updated the commitfest title.
I tried the updated
Peter, thank you for the feedback. Attached is a new patch with "address"
rather than "interface", plus a new default of "local" if there is no
address. I also removed the questionable comment, and updated the
commitfest title.
Cheers,
Greg
From bfa69fc2fffcb29dee0c6acfa4fc3749f987b272 Mon Sep 17
18 matches
Mail list logo
