Re: fsync reliability

Поиск
Список
Период
Сортировка
От Greg Smith
Тема Re: fsync reliability
Дата
Msg-id 4DB1EB42.2090009@2ndQuadrant.com
обсуждение исходный текст
Ответ на Re: fsync reliability  (Simon Riggs <simon@2ndQuadrant.com>)
Ответы Re: fsync reliability  (Matthew Woodcraft <matthew@woodcraft.me.uk>)
Список pgsql-hackers
On 04/22/2011 09:32 AM, Simon Riggs wrote:
> OK, that's good, but ISTM we still have a hole during
> RemoveOldXlogFiles() where we don't fsync or open/close the file, just
> rename it.
>    

This is also something that many applications rely upon working as hoped 
for here, even though it's not technically part of POSIX.  Early 
versions of ext4 broke that, and it caused a giant outcry of 
complaints.  
http://www.h-online.com/open/news/item/Ext4-data-loss-explanations-and-workarounds-740671.html 
has a good summary.  This was broken on ext4 from around 2.6.28 to 
2.6.30, but the fix for it was so demanded that it's even been ported by 
the relatively lazy distributions to their 2.6.28/2.6.29 kernels.

There may be a small window for metadata issues here if you've put the 
WAL on ext2 and there's a crash in the middle of rename.  That factors 
into why any suggestions I make about using ext2 come with a load of 
warnings about the risk of not journaling.  It's hard to predict every 
type of issue that fsck might force you to come to terms with after a 
crash on ext2, and if there was a problem with this path I'd expect it 
to show up as something to be reconciled then.

-- 
Greg Smith   2ndQuadrant US    greg@2ndQuadrant.com   Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support  www.2ndQuadrant.us




В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: "stored procedures"
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: Patch for pg_upgrade to turn off autovacuum