Jean-Denis Girard <jd-girard(at)esoft(dot)pf> 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
(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
pgsql-interfaces by date
|Next:||From: Stephen Martin Trans-Euro I.T Ltd||Date: 1999-07-18 02:35:29|
|Previous:||From: Ansley, Michael||Date: 1999-07-17 10:17:08|
|Subject: RE: query length limits|