Re: Migration study, step 1: bulk write performance

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Mar 21, 2006 at 06:18:39AM -0600, Jim C. Nasby wrote:
> Basically, you need to know for certain that if PostgreSQL creates a
> file and then fsync's it that that file is safely on disk, and that the
> filesystem knows how to find it (ie: the metadata is also on disk in
> some fashion).

It seems to do, quoting Tom from
http://archives.postgresql.org/pgsql-performance/2005-11/msg00184.php:

== snip ==
  No, Mike is right: for WAL you shouldn't need any journaling.  This is
  because we zero out *and fsync* an entire WAL file before we ever
  consider putting live WAL data in it.  During live use of a WAL file,
  its metadata is not changing.  As long as the filesystem follows
  the minimal rule of syncing metadata about a file when it fsyncs the
  file, all the live WAL files should survive crashes OK.

  We can afford to do this mainly because WAL files can normally be
  recycled instead of created afresh, so the zero-out overhead doesn't
  get paid during normal operation.

  You do need metadata journaling for all non-WAL PG files, since we don't
  fsync them every time we extend them; which means the filesystem could
  lose track of which disk blocks belong to such a file, if it's not
  journaled.
== snip ==

/* Steinar */
-- 
Homepage: http://www.sesse.net/


[Postgresql General]     [Postgresql PHP]     [PHP Users]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Yosemite]

  Powered by Linux