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-----
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.