--PSXRUCbmiibGgnYg
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sun, Sep 16, 2007 at 10:37:25AM +1000, Giles Lean wrote:
>=20
> Darren Reed <darrenr@netbsd.org> wrote:
> > Having done that, I'm wondering if it makes sense for NetBSD
> > to support -nomtime as well.  I'm not sure what impact this will
> > have on postgres's operation (does it depend on file modification
> > timestamp changes?) ...
>=20
> I don't think that it does, but the PostgreSQL lists would be the
> canonical place to ask.

Me either, and likewise.

> The typical way to take a backup of PostgreSQL is with pg_dump which
> uses a connection to the running database.  So I don't think it will
> care about filesystem times.
>=20
> Full filesystem backups without the databse running should also be
> safe.
>=20
> A hypothetical user who is making incremental backups after shutting
> down the database could get bitten. =20

Likewise someone doing snapshots and log shipping for PITR with the db
live, if their copying mechanism relied on mtime.

> There's some precedent in other operating systems for not updating the
> mtime on (some) device files e.g. logical volumes and tape drives.
>=20
> [several problem cases]

I think the best would be to defer mtime writes in the same way atime
writes currently are.  That is, the mtime gets updated in memory, but
not on disk until some time later.  This carries the risk of mtime
information loss for a crash or power failure, but doesn't affect
behaviour otherwise.  It gives people a knob if they want to tune
their risk appetite (especially if they have other mitgations like UPS
etc).

> Perhaps you can hack in a 'nomtime' mount flag and see if it makes a
> measurable difference? On a PC with IDE disk(s) with write-back caching
> enabled or a disk array with battery backed write cache the volume of
> mtime writes may be dwarfed by transaction write traffic.  No way to
> tell without testing, though.

Yeah, a quick experiemnt to see if there was an effect was all that
was being proposed.  As a more general solution, providing a knob like
above to enable people in similar situations to do similar experiments
would be handy, even if the outcome of that experiment in the vast
majority of cases is expected to be negligible, and running that way
normally was heavily discouraged.

--
Dan.

--PSXRUCbmiibGgnYg
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (NetBSD)

iD8DBQFG7IlxEAVxvV4N66cRAuPVAKDYSgPQBztjz1YQMI+xDiRW/Bd+oQCg0JRn
HEecWEOB2zOmTVBmQ9MKYRY=
=G1of
-----END PGP SIGNATURE-----

--PSXRUCbmiibGgnYg--