From: | Dave Vitek <dvitek(at)grammatech(dot)com> |
---|---|
To: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Pg Bugs <pgsql-bugs(at)postgresql(dot)org> |
Subject: | Re: Fwd: race in pg_ctl start -w |
Date: | 2012-10-18 19:05:26 |
Message-ID: | 508052F6.20803@grammatech.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On 10/15/2012 4:06 AM, Heikki Linnakangas wrote:
> On 11.10.2012 22:36, Tom Lane wrote:
>> Heikki Linnakangas<hlinnakangas(at)vmware(dot)com> writes:
>>> Hmm, starting with 9.3, postmaster can not only create and append to
>>> the
>>> end of file, it can also inject a line in the middle, shifting the
>>> following lines forwards. In theory, if a new line is injected into the
>>> middle of the file between fgets() calls, readfile() could read part of
>>> the same line twice. Not sure what consequences that could have; pg_ctl
>>> might try to connect to wrong address or socket directory.
>>
>> Hm. IIRC, the postmaster is careful to write the whole thing in a
>> single write() call, which in principle is atomic. Perhaps you're
>> right that we'd better have pg_ctl read it in a single read() to
>> ensure that it sees a consistent file state. Otherwise we're making
>> assumptions about what sort of buffering underlies the stdio functions.
>
> Ok, changed it to slurp the whole file to memory with one read() call.
>
> Dave, did this silence the static analysis tool you used?
>
> - Heikki
Heikki,
It's happy about the overruns. It did flag an issue where the file
descriptor can leak when the various early returns get taken.
- Dave
From | Date | Subject | |
---|---|---|---|
Next Message | henrique.assessoria | 2012-10-18 19:13:08 | BUG #7613: INTIDB |
Previous Message | Tom Lane | 2012-10-18 17:57:04 | Re: BUG #7611: \copy (and COPY?) incorrectly parses nul character for windows-1252 |