From: | Giles Lean <giles(at)nemeton(dot)com(dot)au> |
---|---|
To: | "Mikheev, Vadim" <vmikheev(at)SECTORBASE(dot)COM> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Big 7.1 open items |
Date: | 2000-06-22 11:58:08 |
Message-ID: | 12884.961675088@nemeton.com.au |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> I ment something like this - link(table file, tmp2 file); fsync(tmp2 file);
> unlink(table file); link(tmp file, table file); fsync(table file);
> unlink(tmp file).
I don't see the purpose of the fsync() calls here: link() and unlink()
effect file system metadata, which with normal Unix (but not Linux)
filesystem semantics is written synchronously.
fsync() on a file forces outstanding data to disk; it doesn't effect
the preceding or subsequent link() and unlink() calls unless
McKusick's soft updates are in use.
If the intent is to make sure the files are in particular states
before each of the link() and unlink() calls (i.e. soft updates or
similar functionality are in use) then more than fsync() is required,
since the files can still be updated after the fsync() and before
link() or unlink().
On Linux I understand that a fsync() on a directory will force
metadata updates to that directory to be committed, but that doesn't
seem to be what this code is trying to do either?
Regards,
Giles
From | Date | Subject | |
---|---|---|---|
Next Message | D'Arcy J.M. Cain | 2000-06-22 13:59:26 | Re: Changes to functions and triggers |
Previous Message | Giles Lean | 2000-06-22 11:41:40 | Re: An idea on faster CHAR field indexing |