Re: BUG #17789: process_pgfdw_appname() fails for autovacuum workers
От | Michael Paquier |
---|---|
Тема | Re: BUG #17789: process_pgfdw_appname() fails for autovacuum workers |
Дата | |
Msg-id | Y/MoXUbuZty59gFj@paquier.xyz обсуждение исходный текст |
Ответ на | Re: BUG #17789: process_pgfdw_appname() fails for autovacuum workers (Kyotaro Horiguchi <horikyota.ntt@gmail.com>) |
Ответы |
Re: BUG #17789: process_pgfdw_appname() fails for autovacuum workers
|
Список | 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
Вложения
В списке pgsql-bugs по дате отправления: