Skip site navigation (1) Skip section navigation (2)

Re: pg_upgrade segfaults when given an invalid PGSERVICE value

From: Steve Singer <ssinger(at)ca(dot)afilias(dot)info>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, PostgreSQL-development Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_upgrade segfaults when given an invalid PGSERVICE value
Date: 2013-03-28 19:06:30
Message-ID: 515494B6.6000102@ca.afilias.info (view raw or flat)
Thread:
Lists: pgsql-hackers
On 13-03-26 12:40 AM, Tom Lane wrote:
> Bruce Momjian <bruce(at)momjian(dot)us> writes:
>> On Mon, Mar 25, 2013 at 07:07:42PM -0400, Tom Lane wrote:
>>> Well, plan B would be to invent a replacement function that does have
>>> the ability to return an error message, but that seems like a lot of
>>> work for a problem that's so marginal that it wasn't noticed till now.
>>> (It's not so much creating the function that worries me, it's fixing
>>> clients to use it.)
>>>
>>> Plan C would be to redefine bogus value of PGSERVICE as not an error,
>>> period.
>
>> Given all of these poor options, is defining a PQconndefaults() as
>> perhaps out of memory or a service file problem really not better?
>
> Uh ... no.  In the first place, what evidence have you got that those
> are (and will continue to be) the only two possible causes?  In the
> second place, this still requires changing every client of
> PQconndefaults(), even if it's only to the extent of fixing their
> error message texts.  If we're going to do that, I'd rather ask them
> to change to a more future-proof solution.
>

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.





> 			regards, tom lane
>
>



In response to

Responses

pgsql-hackers by date

Next:From: Robert HaasDate: 2013-03-28 19:46:52
Subject: Re: [sepgsql 1/3] add name qualified creation label
Previous:From: Tom LaneDate: 2013-03-28 17:03:05
Subject: Extra security measures for next week's releases

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group