<p dir="ltr"><br /> On May 25, 2015 5:12 PM, "Stephen Frost" <<a
href="mailto:sfrost@snowman.net">sfrost@snowman.net</a>>wrote:<br /> ><br /> > All,<br /> ><br /> >
(sendingto -core to request a release)<br /> ><br /> > * <a
href="mailto:andrew@tao11.riddles.org.uk">andrew@tao11.riddles.org.uk</a>(<a
href="mailto:andrew@tao11.riddles.org.uk">andrew@tao11.riddles.org.uk</a>)wrote:<br /> > > Operating system:
Debian(and probably others)<br /> ><br /> > > The addition of a recursive fsync of the data dir on startup
(inthe absence<br /> > > of a clean shutdown) causes startup to fail if the data dir contains<br /> > >
symlinksto files which the postgres user can't write to.<br /> > ><br /> > > This is the standard
configurationfor many SSL-enabled setups, including<br /> > > the standard debian packaging defaults.
Accordingly,crash recovery now<br /> > > ALWAYS fails on such systems without manual intervention.<br /> ><br
/>> Andrew did a great job summarizing the problem, don't know that there's<br /> > much to add there.<br />
><br/> > This was back-patched all the way and released with the latest round of<br /> > minor releases, and
giventhat it means crash recovery fails for a large<br /> > number of deployed systems, I think we need to fix (or
revert)the<br /> > recursive fsync change (d8ac77ab178ddb2ae043b8c463cd30c031e793d0 and<br /> > related) and do
newreleases very shortly.<br /> ><p dir="ltr">Agreed, this is a pretty bad regression and we need to at least do
somethingand out out a release asap - either revert or if we can find a better way (see the other thread about this
issuefor some other ideas). <p dir="ltr">It happens to be the default shipment on Debian and Ubuntu but it's definitely
nota platform specific problem I believe, so we should put out a "real" release and not expect packagers to carry a
specificpatch for it. <p dir="ltr">/Magnus