summaryrefslogtreecommitdiff
path: root/doc/src/FAQ/FAQ_irix.html
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2025-10-21 14:10:11 -0400
committerTom Lane <tgl@sss.pgh.pa.us>2025-10-21 14:10:14 -0400
commitfba60a1b107df425ec9676b8cf759830a70def03 (patch)
treebafa713efecea09b30c7452bd36c43ff8ef1a642 /doc/src/FAQ/FAQ_irix.html
parentb97d8d843a2d07547f037e624fec79fd610005bb (diff)
Avoid short seeks in pg_restore.
If a data block to be skipped over is less than 4kB, just read the data instead of using fseeko(). Experimentation shows that this avoids useless kernel calls --- possibly quite a lot of them, at least with current glibc --- while not incurring any extra I/O, since libc will read 4kB at a time anyway. (There may be platforms where the default buffer size is different from 4kB, but this change seems unlikely to hurt in any case.) We don't expect short data blocks to be common in the wake of 66ec01dc4 and related commits. But older pg_dump files may well contain very short data blocks, and that will likely be a case to be concerned with for a long time. While here, do a little bit of other cleanup in _skipData. Make "buflen" be size_t not int; it can't really exceed the range of int, but comparing size_t and int variables is just asking for trouble. Also, when we initially allocate a buffer for reading skipped data into, make sure it's at least 4kB to reduce the odds that we'll shortly have to realloc it bigger. Author: Dimitrios Apostolou <jimis@gmx.net> Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://postgr.es/m/2edb7a57-b225-3b23-a680-62ba90658fec@gmx.net
Diffstat (limited to 'doc/src/FAQ/FAQ_irix.html')
0 files changed, 0 insertions, 0 deletions