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

Поиск
Список
Период
Сортировка
От Kyotaro Horiguchi
Тема Re: BUG #17789: process_pgfdw_appname() fails for autovacuum workers
Дата
Msg-id 20230215.161254.1131534874642120926.horikyota.ntt@gmail.com
обсуждение исходный текст
Ответ на Re: BUG #17789: process_pgfdw_appname() fails for autovacuum workers  (Masahiko Sawada <sawada.mshk@gmail.com>)
Ответы Re: BUG #17789: process_pgfdw_appname() fails for autovacuum workers  (Michael Paquier <michael@paquier.xyz>)
Список pgsql-bugs
At Tue, 14 Feb 2023 17:02:45 +0900, Masahiko Sawada <sawada.mshk@gmail.com> wrote in 
> On Tue, Feb 14, 2023 at 2:05 PM Kyotaro Horiguchi
> <horikyota.ntt@gmail.com> wrote:
> >
> > At Mon, 13 Feb 2023 05:00:01 +0000, PG Bug reporting form <noreply@postgresql.org> wrote in
> > > CREATE FOREIGN TABLE ft1 (b int) INHERITS (t1)
> > >         SERVER LOOPBACK OPTIONS (table_name 'anytable');
> >
> > Yeah, the autovacuum processes t1 and then its child foreign table
> > ft1. MyProcPort is NULL on autovacuum processes. This doesn't happen
> > for partitioned tables.
> >
> > > #5  0x0000564b2ecc55c8 in ExceptionalCondition
> > > (conditionName=conditionName@entry=0x7fb1feb3f81e "MyProcPort != NULL",
> > >     errorType=errorType@entry=0x7fb1feb3e700 "FailedAssertion",
> > > fileName=fileName@entry=0x7fb1feb3f75a "option.c",
> > >     lineNumber=lineNumber@entry=464) at assert.c:69
> > > #6  0x00007fb1feb31b30 in process_pgfdw_appname (appname=<optimized out>) at
> > > option.c:464
> >
> > Commit 6e0cb3dec1 overlooked the case of autovacuum analyzing foreign
> > tables as an inheritance child. We thought NULL MyProcPort was
> > impossible in the discussion for the patch. Using %d and %u in
> > postgres_fdw.application_name we hit the bug.
> >
> > The following change fixes the bug.
> 
> The change seems to work fine.

Thanks for veryfiying that!

> > - Is it okay to use '-' as %u (user name) and %d (databsae name) in
> >   the NULL MyProcPort case?
> 
> Another idea seems to not display anything in this case, which is
> consistent with what log_status_format() does.

As you said, when MyProcPort is NULL, the function won't insert
anything unless padding is specified. But in this case, padding isn't
even a thing. So it seems best to not insert anything.

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]'.

> > - Do we need tests for the case? They need to wait for autovacuum to run.
> 
> Not sure it's worth having tests for that as the fix is obvious.

Thanks you for sharing your thoughts.  I'll go with that.

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center



В списке pgsql-bugs по дате отправления:

Предыдущее
От: PG Bug reporting form
Дата:
Сообщение: BUG #17795: Erroneous parsing of floating-poing components in DecodeISO8601Interval()
Следующее
От: Dean Rasheed
Дата:
Сообщение: Re: BUG #17792: MERGE uses uninitialized pointer and crashes when target tuple is updated concurrently