Horton

Thread

Commits

  1. Enlarge find_other_exec's meager fgets buffer

  1. initdb fails to initialize data directory

    Nikhil Sontakke <nikhils@2ndquadrant.com> — 2018-04-19T08:52:33Z

    Hi,

Encountered the following behavior with initdb on one of our test
builds while using latest master head:

initdb -D $DATADIR

The program "postgres" was found by "/Users/nikhils/install/bin/initdb"
but was not the same version as initdb.
Check your installation.

Intrigued, on digging down further, this is happening because we are
not using a long enough buffer to accept the output of "postgres -V"
in the find_other_exec() function. In our case, we had used
--with-extra-version option with configure which caused the output of
"postgres -V" to go a little beyond the current "line" variable size.
This caused the strcmp to fail leading to initdb refusing to
initialize any data directories at all.

PFA, a patch which uses MAXPGPATH for the variable size.

Regards,
Nikhils
-- 
 Nikhil Sontakke                   http://www.2ndQuadrant.com/
 PostgreSQL/Postgres-XL Development, 24x7 Support, Training & Services

  2. Re: initdb fails to initialize data directory

    Alvaro Herrera <alvherre@alvh.no-ip.org> — 2018-04-19T13:38:43Z

    Nikhil Sontakke wrote:

> Intrigued, on digging down further, this is happening because we are
> not using a long enough buffer to accept the output of "postgres -V"
> in the find_other_exec() function. In our case, we had used
> --with-extra-version option with configure which caused the output of
> "postgres -V" to go a little beyond the current "line" variable size.
> This caused the strcmp to fail leading to initdb refusing to
> initialize any data directories at all.

Wow, that seems pretty silly nowadays.

Will push in a jiffy.

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

  3. Re: initdb fails to initialize data directory

    Heikki Linnakangas <hlinnaka@iki.fi> — 2018-04-19T19:15:30Z

    On 19/04/18 09:38, Alvaro Herrera wrote:
> Nikhil Sontakke wrote:
> 
>> Intrigued, on digging down further, this is happening because we are
>> not using a long enough buffer to accept the output of "postgres -V"
>> in the find_other_exec() function. In our case, we had used
>> --with-extra-version option with configure which caused the output of
>> "postgres -V" to go a little beyond the current "line" variable size.
>> This caused the strcmp to fail leading to initdb refusing to
>> initialize any data directories at all.
> 
> Wow, that seems pretty silly nowadays.

Agreed.

Nitpick: using MAXPGPATH seems for the buffer size seems to wrong to me. 
We're not storing a path here. MAXPGPATH is 1024 by default, which seems 
fine, but I would've spelled it out directly as "line[1000]".

- Heikki

  4. Re: initdb fails to initialize data directory

    Alvaro Herrera <alvherre@alvh.no-ip.org> — 2018-04-19T19:59:44Z

    Heikki Linnakangas wrote:

> Nitpick: using MAXPGPATH seems for the buffer size seems to wrong to me.
> We're not storing a path here. MAXPGPATH is 1024 by default, which seems
> fine, but I would've spelled it out directly as "line[1000]".

Hmm ... yeah, kinda.  Do you care about it strongly enough for me to fix
it in all branches?

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

  5. Re: initdb fails to initialize data directory

    Michael Paquier <michael@paquier.xyz> — 2018-04-20T00:03:35Z

    On Thu, Apr 19, 2018 at 04:59:44PM -0300, Alvaro Herrera wrote:
> Heikki Linnakangas wrote:
>> Nitpick: using MAXPGPATH seems for the buffer size seems to wrong to me.
>> We're not storing a path here. MAXPGPATH is 1024 by default, which seems
>> fine, but I would've spelled it out directly as "line[1000]".
> 
> Hmm ... yeah, kinda.  Do you care about it strongly enough for me to fix
> it in all branches?

Perhaps that's not worth bothering, but using MAXPGPATH which is for
file and folder paths for a line read ffrom a command output is
disturbing.  So like Heikki I would suggest to just remove the reference
and use a hardcoded, independent, size (could add a comment as well).
--
Michael