Re: Retry Cached Remote Connections for postgres_fdw in case remote backend gets killed/goes away
От | Fujii Masao |
---|---|
Тема | Re: Retry Cached Remote Connections for postgres_fdw in case remote backend gets killed/goes away |
Дата | |
Msg-id | 182fb357-a264-88fe-cbb7-bf0f1563edbe@oss.nttdata.com обсуждение исходный текст |
Ответ на | Re: Retry Cached Remote Connections for postgres_fdw in case remote backend gets killed/goes away (Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>) |
Список | pgsql-hackers |
On 2020/10/05 20:32, Bharath Rupireddy wrote: > On Mon, Oct 5, 2020 at 9:45 AM Fujii Masao <masao.fujii@oss.nttdata.com> wrote: >> >>> I see the errmsg() with plain texts in other places in the code base >>> as well. Is it that we look at the error message and if it is a plain >>> text(without database objects or table data), we decide to have no >>> translation? Or is there any other policy? >> >> I was thinking that elog() basically should be used to report this >> debug message, instead, but you used ereport() because maybe >> you'd like to add detail message about connection error. Is this >> understanding right? elog() uses errmsg_internal(). >> > > Yes that's correct. > >> >> So if ereport() is used as an aternative of elog() for some reasons, >> IMO errmsg_internal() should be used. Thought? >> > > Yes, this is apt for our case. > >> >> OTOH, the messages you mentioned are not debug ones, >> so basically ereport() and errmsg() should be used, I think. >> > > In connection.c file, yes they are of ERROR type. Looks like it's not > a standard to use errmsg_internal for DEBUG messages that require no > translation with ereport > > (errmsg("wrote block details for %d blocks", num_blocks))); > (errmsg("MultiXact member stop limit is now %u based on MultiXact %u > (errmsg("oldest MultiXactId member is at offset %u", > > However, there are few other places, where errmsg_internal is used for > DEBUG purposes. > > (errmsg_internal("finished verifying presence of " > (errmsg_internal("%s(%d) name: %s; blockState: > > Having said that, IMHO it's better to keep the way it is currently in > the code base. Agreed. > >> >>> Thanks. Attaching v10 patch. Please have a look. >> >> Thanks for updating the patch! I will mark the patch as ready for committer in CF. >> Barring any objections, I will commit that. >> > > Thanks a lot for the review comments. I pushed the patch. Thanks! Regards, -- Fujii Masao Advanced Computing Technology Center Research and Development Headquarters NTT DATA CORPORATION
В списке pgsql-hackers по дате отправления: