Re: Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
От | Andres Freund |
---|---|
Тема | Re: Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb) |
Дата | |
Msg-id | 201002141827.04993.andres@anarazel.de обсуждение исходный текст |
Ответ на | Re: Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb) (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
|
Список | pgsql-hackers |
On Sunday 14 February 2010 18:11:39 Tom Lane wrote: > Greg Stark <gsstark@mit.edu> writes: > > So I think we have a bigger problem than just copydir.c. It seems to > > me we should be fsyncing the table space data directories on every > > checkpoint. > > Is there any evidence that anyone anywhere has ever lost data because > of a lack of directory fsyncs? I sure don't recall any bug reports > that seem to match that theory. I have actually seen the issue during create database at least. In a virtualized hw though... ~1GB template database, lots and lots of small tables, the crash occured maybe a minute after CREATE DB, filesystem was xfs, kernel 2.6.30.y. > It seems to me that we're talking about a huge hit in both code > complexity and performance to deal with a problem that doesn't actually > occur in the field; and which furthermore is trivially solved on any > modern filesystem by choosing the right filesystem options. Why don't > we just document those options, instead? Which options would that be? I am not aware that there any for any of the recent linux filesystems. Well, except "sync" that is, but that sure would be more of a performance hit than fsyncing the directory... Andres
В списке pgsql-hackers по дате отправления: