Re: BUG #17789: process_pgfdw_appname() fails for autovacuum workers

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
Cc: sawada(dot)mshk(at)gmail(dot)com, exclusion(at)gmail(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #17789: process_pgfdw_appname() fails for autovacuum workers
Date: 2023-02-20 07:59:25
Message-ID: Y/MoXUbuZty59gFj@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Wed, Feb 15, 2023 at 04:12:54PM +0900, Kyotaro Horiguchi wrote:
> By the way, when we designed that part, we first concluded that the
> user name and database name cannot be NULL before we later concluded
> that MyProcPort cannot be NULL. However, log_status_format() takes
> into account the case where MyProcPort stores NULL as user and
> database names. Do you think we should still ignore the case of NULL
> user name and database names, even though our assumption about
> MyProcPort was found to be incorrect? In that case,
> log_status_format() replaces, for example, %u with '[unknown]'.

Hmm. I think that I would play it safe but consistent here for %d and
%u as this code could be triggered in various contexts as far as I
understand:
- When MyProcPort is NULL, insert no data, because there is nothing to
report.
- When MyProcPort is not NULL but the %d or %u field is NULL, use
[unknown], because we just don't know what to show up, still there is
a MyProcPort.

This has the advantage to be able to make the difference in both
cases, which could be important for the end-user depending on the
context where the code is run.
--
Michael

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Alexander Lakhin 2023-02-20 10:00:00 Re: BUG #17795: Erroneous parsing of floating-poing components in DecodeISO8601Interval()
Previous Message Kyotaro Horiguchi 2023-02-20 02:00:50 Re: Create user mapping without password