Re: Issue in postgres_fdw causing unnecessary wait for cancel request reply
От | Robert Haas |
---|---|
Тема | Re: Issue in postgres_fdw causing unnecessary wait for cancel request reply |
Дата | |
Msg-id | CA+Tgmoa+C5Y_2bukjrPHszjkZYDVQqHvUFjWpZZywJ4S2JD1ug@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Issue in postgres_fdw causing unnecessary wait for cancel request reply (Fujii Masao <masao.fujii@oss.nttdata.com>) |
Список | pgsql-hackers |
On Thu, Apr 13, 2023 at 2:04 PM Fujii Masao <masao.fujii@oss.nttdata.com> wrote: > >> To clarify, are you suggesting that PQgetCancel() should > >> only parse the parameters for TCP connections > >> if cancel->raddr.addr.ss_family != AF_UNIX? > >> If so, I think that's a good idea. > > > > You're right. I used connip in the diff because I thought it provided > > the same condition, but in a simpler way. > > I made a modification to the 0001 patch. It will now allow PQgetCancel() to parse and interpret TCP connection parametersonly when the connection is not made through a Unix-domain socket. I don't really like this change. It seems to me that what this does is decide that it's not an error to set tcp_user_timeout='a' when making a cancel request if the connection doesn't actually use TCP. I agree that we shouldn't try to *use* the values if they don't apply, but I'm not sure it's a good idea to skip *sanity-checking* them when they don't apply. For instance you can't set work_mem=ssdgjsjdg in postgresql.conf even if you never run a query that needs work_mem. -- Robert Haas EDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: