Re: fsync-pgdata-on-recovery tries to write to more files than previously
От | Magnus Hagander |
---|---|
Тема | Re: fsync-pgdata-on-recovery tries to write to more files than previously |
Дата | |
Msg-id | CABUevEwSGNys7GXyeTmFbMR-XA3RQVqY5BEfFxtoYFWs_9Ci1g@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: fsync-pgdata-on-recovery tries to write to more files than previously (Andrew Dunstan <andrew@dunslane.net>) |
Список | pgsql-hackers |
On Tue, May 26, 2015 at 6:16 PM, Andrew Dunstan <andrew@dunslane.net> wrote:
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 absolutelyIf we try to be selective, we risk errors of omission, which no one would
everything? That seems over-broad.
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_".
Not just "people". initdb will symlink the xlog directory if you use -x.
В списке pgsql-hackers по дате отправления: