Re: fsync-pgdata-on-recovery tries to write to more files than previously - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: fsync-pgdata-on-recovery tries to write to more files than previously
Date
Msg-id 55649C72.9010304@dunslane.net
Whole thread Raw
In response to Re: fsync-pgdata-on-recovery tries to write to more files than previously  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses 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
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: fsync-pgdata-on-recovery tries to write to more files than previously
Next
From: Magnus Hagander
Date:
Subject: Re: fsync-pgdata-on-recovery tries to write to more files than previously