Re: fsync-pgdata-on-recovery tries to write to more files than previously

On Tue, May 26, 2015 at 6:16 PM, Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:

>
> On 05/26/2015 11:58 AM, Tom Lane wrote:
>
>> Andrew Dunstan <andrew(at)dunslane(dot)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_".
>

Not just "people". initdb will symlink the xlog directory if you use -x.

--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/