Re: Add pg_file_sync() to adminpack
Stephen Frost <[email protected]>
| Newsgroups | gmane.comp.db.postgresql.devel.general |
|---|---|
| Message-ID | <[email protected]> |
Greetings, * Julien Rouhaud ([email protected]) wrote: > On Thu, Jan 9, 2020 at 7:43 AM Fujii Masao <[email protected]> wrote: > > On Wed, Dec 25, 2019 at 11:11 PM Julien Rouhaud <[email protected]> wrote: > > > On Wed, Dec 25, 2019 at 2:01 PM Fujii Masao <[email protected]> wrote: > > > > I'd like to propose to add pg_file_sync() function into contrib/adminpack. > > > > This function fsyncs the specified file or directory named by its argument. > > > > IMO this is useful, for example, when you want to fsync the file that > > > > pg_file_write() writes out or that COPY TO exports the data into, > > > > for durability. Thought? > > > > > > +1, that seems like a useful wrapper. Looking at existing functions, > > > I see that there's a pg_file_rename() in adminpack, but it doesn't use > > > durable_rename nor does it try to perform any fsync. Same for > > > pg_file_unlink vs. durable_unlink. It's probably worth fixing that at > > > the same time? > > > > I don't think that's a bug. I'm not sure if every users of those functions > > need durable rename and unlink at the expense of performance. > > So IMO it's better to add new argument like "durable" to those functions > > and durable_rename or _unlink is used only if it's true. > > It's probably a POLA violation. I'm pretty sure that most people > using those functions would expect that a successful call to > pg_file_unlink() mean that the file cannot raise from the dead even > with certain unlikely circumstances, at least I'd expect so. If > performance is a problem here, I'd rather have a new wrapper with a > sync flag that defaults to true so it's possible to disable it if > needed instead of calling a different function. That being said, I > agree with Arthur, it should be handled in a different patch. Why would you expect that when it isn't the case for the filesystem itself..? I agree with Fujii on this- you should have to explicitly ask for us to do more than the equivilant filesystem-level operation. We shouldn't be forcing that on you. Thanks, Stephen
signature.asc
(application/pgp-signature, 819 B)
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCgAGBQJeF1/WAAoJEO1sijiDR2RVlq4P/RrvIw0CtiRjr/mk4nBMw8tJ /GxfUAjS54tCwi1wg7R0Gv3Dx7VlUAFXfYb69sGv0DIjMqnhTT0Mrijw7DckEMAI Hu/aTXsZPFZYdKNkHX9zqD99VFl4nQVst87oDQq3mKdBmkXxmgFg5Ar8VHQ9RtjG iW8f1IygY5Qrj3Hv5LJzTchCPre8e7FfHyWgXfJIkWaU69ER3YcY5wtlABhJV/4B TkUhZcKeha5gS3Ta5DxHWW8RaLf/pkZNLG9mgDPKsm2u1oHHPaFELSEXT5MMural V/59Kz9Km/vtc4HMttRxab5agLaYir87k95wzec28y/aE5o+tBr+VbQDeHND1Kcs Jvb3NOJfa6usF6pFTs+PElfl0mWetIuFRBS5cOTcq2xm29CufkDD6HGEoxJMpPEp N2MLQbL7MuVc9buItPVxWiktH9q7zFmCR41z5wva77rD5P16xFuX5noBUuvXFiam uP2NVd9maJOf1k+5vMxrFWMsvvvi94WBo6mpNPUFjhfivojCMfUb5JnSPMD8S0pO jzjWEIXR75oQ7wqkWSGzCg5slc+wyAQcwzdrDm/eCm++NJjWW8zvhmXsGuksxErr 4l6six9KikPz3SELC3ShvlUOlN1/FWRGjuGz5V2Vz4JBDF1j3fVgXTHooN7FtjzL ZuHcp++n5IZA/1rgLVgZ =z04n -----END PGP SIGNATURE-----