Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2] (may be forged)) by hub.org (8.9.3/8.9.3) with ESMTP id LAA70611 for ; Sat, 17 Jul 1999 11:58:57 -0400 (EDT) (envelope-from tgl@sss.pgh.pa.us) Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id LAA19840; Sat, 17 Jul 1999 11:57:27 -0400 (EDT) To: Jean-Denis Girard cc: pgsql-interfaces@postgreSQL.org Subject: Re: [INTERFACES] Postgres 6.5 and PQsetdb(,,"-F",,) In-reply-to: Your message of Fri, 16 Jul 1999 22:27:35 -1000 <37903E77.6496853F@esoft.pf> Date: Sat, 17 Jul 1999 11:57:27 -0400 Message-ID: <19838.932227047@sss.pgh.pa.us> From: Tom Lane Jean-Denis Girard writes: > I just upgraded from Postgres 6.3.2 (shipped with RedHat) to latest 6.5 > on a Linux system, with an existing application. > Everything went smoothly, but it seems that "-F" option in PQsetdb > no longer works. > I tried to launch postmaster with -F option and it works as expected, > but I really want to enable /disable fsync from libp, so I can run > lengthly updates of my database reasonnably fast at the risk of problems > if the system crash, and keep safe fsync for short opearations. -F, as well as some other potentially dangerous backend command-line switches, is no longer accepted from clients' PGOPTIONS strings. As of 6.5, these switches can only be specified on the postmaster command line (or when starting a standalone backend for debugging). The reason -F is considered dangerous is that it only works right when all the backends are doing things the same way. The shared-memory buffer pool is a community resource, so any one of the backends might be the one that writes a particular dirty buffer to disk. Now suppose that you are working on a critical table and so you want fsync's to occur. You modify a page of the table. Before you get around to writing it, some other backend needs the buffer slot and so writes out the page for you. If that other backend is not using fsync, are you happy? You are not. You just lost the guarantee you were trying to achieve, that your page updates will hit the disk in a known order. So -F has to be an "all or nothing" proposition. You cannot control it on a per-backend basis, at least not if you want predictable behavior. (You could get away with it if you never have more than one backend running at a time, but in that case you could restart the postmaster every time you want to change the -F status.) Even if the behavior were predictable, allowing unprivileged users to downgrade the reliability of the server seems like a serious security breach. As a DB admin, I'd want to think that whether to use -F is my decision and can't be overridden by any user who takes it into his head to do so... regards, tom lane