From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | hlinnaka(at)iki(dot)fi |
Cc: | Pg Bugs <pgsql-bugs(at)postgresql(dot)org>, Dave Vitek <dvitek(at)grammatech(dot)com> |
Subject: | Re: Fwd: race in pg_ctl start -w |
Date: | 2012-10-11 17:29:52 |
Message-ID: | 22107.1349976592@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Heikki Linnakangas <hlinnaka(at)iki(dot)fi> writes:
> A straightforward fix would be to just allocate one large-enough buffer
> to begin with, e.g 8k, and read the whole file in one go. I'll write up
> a patch for that.
This makes the readfile function very usage-specific though. The fix
I was thinking about was to modify the second loop to force it to fall
out once the predetermined number of lines had been read.
Or maybe we should use just one loop with realloc, instead of reading
the file twice.
>> It also flagged a very similar issue (looks like the code was copied &
>> pasted) in initdb.c. I haven't looked into whether that one is as
>> likely to be subject to a race as the pg_ctl one, but it could be
>> problematic as well.
> I don't think it's a problem for initdb, because the files that it reads
> should not change on the fly. Nevertheless, I guess we might as well add
> a check there.
Yeah, I would prefer to keep the code the same in initdb and pg_ctl,
just because somebody is likely to copy one or the other in future.
The fixed-size-buffer solution does not work for initdb.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2012-10-11 18:59:31 | Re: Fwd: race in pg_ctl start -w |
Previous Message | Heikki Linnakangas | 2012-10-11 17:17:23 | Fwd: race in pg_ctl start -w |