From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>, Greg Stark <stark(at)mit(dot)edu>, Magnus Hagander <magnus(at)hagander(dot)net>, Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Andres Freund <andres(at)anarazel(dot)de>, Christoph Berg <myon(at)debian(dot)org> |
Subject: | Re: fsync-pgdata-on-recovery tries to write to more files than previously |
Date: | 2015-05-26 15:58:00 |
Message-ID: | 16539.1432655880@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
> And might it be better to check that we can open each file using
> access() than calling open() and looking at the error code?
Don't really see the point; that's just an extra step, and access()
won't exactly prove you can open the file, anyway.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2015-05-26 16:16:50 | Re: fsync-pgdata-on-recovery tries to write to more files than previously |
Previous Message | Paul Smith | 2015-05-26 15:47:15 | Re: ERROR: MultiXactId xxxx has not been created yet -- apparent wraparound |