On Mon, May 25, 2015 at 9:54 PM, Stephen Frost <sfr...@snowman.net> wrote: > I certainly see your point, but Tom also pointed out that it's not great > to ignore failures during this phase: > > * Tom Lane (t...@sss.pgh.pa.us) wrote: >> Greg Stark <st...@mit.edu> writes: >> > What exactly is failing? >> > Is it that fsync is returning -1 ? >> According to the original report from Christoph Berg, it was open() >> not fsync() that was failing, at least in permissions-based cases. >> >> I'm not sure if we should just uniformly ignore all failures in this >> phase. That would have the merit of clearly not creating any new >> startup failure cases compared to the previous code, but as you say >> sometimes it might mean ignoring real problems. > > If we accept this, then we still have to have the lists, to decide what > to fail on and what to ignore. If we're going to have said lists tho, I > don't really see the point in fsync'ing things we're pretty confident > aren't ours.
No, that's not right at all. The idea, at least as I understand it, would be decide which errors to ignore by looking at the error code, not by looking at which file is involved. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers