Re: [HACKERS] New pg_ctl has retrogressed in error messages - Mailing list pgsql-patches

From Andrew Dunstan
Subject Re: [HACKERS] New pg_ctl has retrogressed in error messages
Date
Msg-id 40BBD6BB.2060306@dunslane.net
Whole thread Raw
In response to Re: [HACKERS] New pg_ctl has retrogressed in error messages  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [HACKERS] New pg_ctl has retrogressed in error messages  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-patches

Tom Lane wrote:

>Bruce Momjian <pgman@candle.pha.pa.us> writes:
>
>
>>I also changed all the pid variables to use pid_t.
>>
>>
>
>Good, but ...
>
>
>
>>!     fscanf(pidf, "%u", &pid);
>>
>>
>
>this code will fail rather horribly if sizeof(pid_t) != sizeof(int).
>Even more to the point, I believe a standalone backend will put
>the negative of its PID into the file, and the revised code will fail
>to parse that at all.
>
>I think the safest code would be like
>
>    long    tmp;
>
>    fscanf(pidf, "%ld", &tmp);
>    if (tmp < 0)
>    {
>        tmp = -tmp;
>        // do anything else needed for backend case
>    }
>    pid = (pid_t) tmp;
>
>
>
>

I deliberately used a signed long for these reasons in the first place.

The number of places we actually need to use this value as a pid is
small (3 by my count - in calls to kill() ), and it was cast there to
pid_t,  I think.  I still don't see what's wrong with that.

cheers

andrew


pgsql-patches by date:

Previous
From: Tom Lane
Date:
Subject: Re: [HACKERS] New pg_ctl has retrogressed in error messages
Next
From: Bruce Momjian
Date:
Subject: Re: [HACKERS] New pg_ctl has retrogressed in error messages