Re: Big 7.1 open items

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

Browse pgsql-hackers by date

  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