On Mon, Jul 3, 2017 at 3:55 PM, Amit Kapila <amit.kapil...@gmail.com> wrote: > On Fri, Jun 23, 2017 at 3:22 AM, Robert Haas <robertmh...@gmail.com> wrote: >> On Thu, Jun 15, 2017 at 12:35 AM, Mithun Cy <mithun...@enterprisedb.com> >> wrote: >> >> * Instead of creating our own buffering system via buffer_file_write() >> and buffer_file_flush(), why not just use the facilities provided by >> the operating system? fopen() et. al. provide buffering, and we have >> AllocateFile() to provide a FILE *; it's just like >> OpenTransientFile(), which you are using, but you'll get the buffering >> stuff for free. Maybe there's some reason why this won't work out >> nicely, but off-hand it seems like it might. It looks like you are >> already using AllocateFile() to read the dump, so using it to write >> the dump as well seems like it would be logical. >> > > One thing that is worth considering is AllocateFile is recommended to > be used for short operations. Refer text atop AllocateFile(). If the > number of blocks to be dumped is large, then the file can remain open > for the significant period of time.
-- Agree. I think I need suggestion on this we will hold on to 1 fd, but I am not sure what amount of time file being opened qualify as a case against using AllocateFile(). -- Thanks and Regards Mithun C Y EnterpriseDB: http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
