Re: pg_upgrade segfaults when given an invalid PGSERVICE value - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: pg_upgrade segfaults when given an invalid PGSERVICE value
Date
Msg-id 20131129211400.GA26132@momjian.us
Whole thread Raw
In response to Re: pg_upgrade segfaults when given an invalid PGSERVICE value  (Steve Singer <ssinger@ca.afilias.info>)
Responses Re: pg_upgrade segfaults when given an invalid PGSERVICE value
List 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. +

Attachment

pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: MultiXact truncation, startup et al.
Next
From: Kevin Grittner
Date:
Subject: Re: MultiXact bugs