| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | Stas Kelvich <s(dot)kelvich(at)postgrespro(dot)ru>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: fd.c: flush data problems on osx |
| Date: | 2016-04-13 22:09:18 |
| Message-ID: | 2114.1460585358@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Andres Freund <andres(at)anarazel(dot)de> writes:
> On 2016-04-13 17:44:41 -0400, Tom Lane wrote:
>> fd.c tracks seek position for open files. I'm not sure that that
>> function can get called with amount == 0, but if it did, the caller
>> would certainly not be expecting the file position to change.
> Ok, fair enough. (And no, it should currently be never called that way)
BTW, I just noticed another issue here, which is that FileWriteback
and the corresponding smgr routines are declared with bogusly narrow
"amount" arguments --- eg, it's silly that FileWriteback only takes
an int amount. I think this code could be actively broken for
relation segment sizes exceeding 2GB, and even if it isn't, we should
define the functions correctly the first time.
Will fix the function definitions, but I'm kind of wondering exactly how
many times the inner loop in IssuePendingWritebacks() could possibly
iterate ...
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2016-04-13 22:10:39 | Re: Missing PG_INT32_MIN in numutils.c |
| Previous Message | Andres Freund | 2016-04-13 21:48:19 | Re: fd.c: flush data problems on osx |