From: | Anastasia Lubennikova <a(dot)lubennikova(at)postgrespro(dot)ru> |
---|---|
To: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | File system operations. |
Date: | 2016-09-15 15:01:06 |
Message-ID: | 7c702f13-3270-863a-9874-69818aa2adbd@postgrespro.ru |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi, hackers!
Do we have any standard set of functions to operate with files?
I mean link(), copy(), rename(), unlink(), ftruncate() and so on.
Mostly I worry about the first two since they have different
implementation on Windows.
I found a couple of functions in src/backend/storage/file/copydir.c,
some more in src/bin/pg_upgrade/file.c along with a set of defines
in src/bin/pg_upgrade/pg_upgrade.h. Obviously md.c and fd.c contain
some functions.
Do we have any policy of using them? There is a comment in fd.c
* For this scheme to work, most (if not all) routines throughout the
* server should use these interfaces instead of calling the C library
* routines (e.g., open(2) and fopen(3)) themselves. Otherwise, we
* may find ourselves short of real file descriptors anyway.
and even more in fd.h
* File {Close, Read, Write, Seek, Tell, Sync}
* {Path Name Open, Allocate, Free} File
*
* These are NOT JUST RENAMINGS OF THE UNIX ROUTINES.
* Use them for all file activity...
but I see that, for example, pg_open_tzfile() and get_controlfile(),
logfile_open()
call open()/fopen() directly. Same behavior you can find for any C
library function.
Am I missing something important or it is simply a legasy/overlooked code?
What do you think about moving stuff from pg_upgrade/file.c to storage/file/
to allow reuse of this code? I think it'll be really helpful for
developers of contrib modules
like backup managers.
--
Anastasia Lubennikova
Postgres Professional:http://www.postgrespro.com
The Russian Postgres Company
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2016-09-15 15:03:23 | Re: Printing bitmap objects in the debugger |
Previous Message | Robert Haas | 2016-09-15 14:46:47 | Re: Surprising behaviour of \set AUTOCOMMIT ON |