Re: pg_upgrade segfaults when given an invalid PGSERVICE value
От | Bruce Momjian |
---|---|
Тема | Re: pg_upgrade segfaults when given an invalid PGSERVICE value |
Дата | |
Msg-id | 20131129211400.GA26132@momjian.us обсуждение исходный текст |
Ответ на | Re: pg_upgrade segfaults when given an invalid PGSERVICE value (Steve Singer <ssinger@ca.afilias.info>) |
Ответы |
Re: pg_upgrade segfaults when given an invalid PGSERVICE
value
|
Список | pgsql-hackers |
On Thu, Mar 28, 2013 at 03:06:30PM -0400, Steve Singer wrote: > So to summarise: > > Plan A: The first patch I attached for pg_upgrade + documentation > changes, and changing the other places that call PQconndefaults() to > accept failures on either out of memory, or an invalid PGSERVICE > > Plan B: Create a new function PQconndefaults2(char * errorBuffer) or > something similar that returned error information to the caller. > > Plan C: PQconndefaults() just ignores an invalid service but > connection attempts fail because other callers of > conninfo_add_defaults still pay attention to connection failures. > This is the second patch I sent. > > Plan D: Service lookup failures are always ignored by > conninfo_add_defaults. If you attempt to connect with a bad > PGSERVICE set it will behave as if no PGSERVICE value was set. I > don't think anyone explicitly proposed this yet. > > Plan 'D' is the only option that I'm opposed to, it will effect a > lot more applications then ones that call PQconndefaults() and I > feel it will confuse users. > > I'm not convinced plan B is worth the effort of having to maintain > two versions of PQconndefaults() for a while to fix a corner case. OK, I am back to looking at this issue from March. I went with option C, patch attached, which seems to be the most popular. It is similar to Steve's patch, but structured differently and includes a doc patch. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. +
Вложения
В списке pgsql-hackers по дате отправления: