Re: fsync-pgdata-on-recovery tries to write to more files than previously
От | Andrew Dunstan |
---|---|
Тема | Re: fsync-pgdata-on-recovery tries to write to more files than previously |
Дата | |
Msg-id | 55649C72.9010304@dunslane.net обсуждение исходный текст |
Ответ на | Re: fsync-pgdata-on-recovery tries to write to more files than previously (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: fsync-pgdata-on-recovery tries to write to more files
than previously
Re: fsync-pgdata-on-recovery tries to write to more files than previously |
Список | pgsql-hackers |
On 05/26/2015 11:58 AM, Tom Lane wrote: > Andrew Dunstan <andrew@dunslane.net> writes: >> OK, I'm late to the party. But why exactly are we syncing absolutely >> everything? That seems over-broad. > If we try to be selective, we risk errors of omission, which no one would > ever notice until someone's data got eaten in a low-probability crash > scenario. It seems more robust (at least to me) to fsync everything we > can find. That does require more thought about error cases than went > into the original patch ... but I think that we need more thought about > error cases even if we do try to be selective. > > One thing perhaps we *should* be selective about, though, is which > symlinks we try to follow. I think that a good case could be made > for ignoring symlinks everywhere except in the pg_tablespace directory. > If we did, that would all by itself take care of the Debian scenario, > if I understand that case correctly. People have symlinked the xlog directory. I've done it myself in the past. A better rule might be to ignore symlinks unless either they are in pg_tblspc or they are in the data directory and their name starts with "pg_". cheers andrew
В списке pgsql-hackers по дате отправления: