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

* Andres Freund (andres(at)anarazel(dot)de) wrote:
> On 2015-05-25 14:02:28 -0400, Tom Lane wrote:
> > Stephen Frost <sfrost(at)snowman(dot)net> writes:
> > > I've not followed this thread all that closely, but I do tend to agree
> > > with the idea of "only try to mess with files that are *clearly* ours to
> > > mess with."
> >
> > Well, that opens us to errors of omission, ie failing to fsync things we
> > should have.
>
> Is that really that likely? I mean we don't normally add data to the top
> level directory itself, and subdirectories hopefully won't be added
> except via initdb?

That feels like a pretty low risk, to me at least. Certainly better
than having a failure, like what's going on now.

> > Maybe that's an okay risk, but personally I'd judge that
> > "fsync everything and ignore (some?) errors" is probably a more robust
> > approach over time.
>
> The over-the-top approach would be to combine the two. Error out in
> directories that are in the initdb list, and ignore permission errors
> otherwise...

That seems overly complicated, for my 2c at least. I don't particularly
like trying to mess with files that might be rightfully considered "not
ours" either. This all makes me really wonder about
postgresql.auto.conf too.. Clearly, on the one hand, we consider that
"our" file, and so we should error out if we don't own it, but on the
other hand, I've specifically recommended making that file owned by
root to some folks, to avoid DBAs playing with the startup-time
settings..

> Additionally we could attempt to fsync with a readonly fd before trying
> the read-write fd...

Not really sure I see that as helping.

Thanks!

Stephen