On 01/31/2016 01:25 PM, Alvaro Herrera wrote:
This hasn't been updated in a long time; I should have closed it
earlier. Chatting with Tomas about it, he seemed inclined to just have
the patch rejected because it's not terribly useful anyway.
we've discussed that some time ago and my memory is a bit flaky, but I
don't think that's quite what I said. The main reason why I haven't
posted an updated version of the patch is that it seems a bit silly to
spend time on this while the underlying data loss issue is still not
fixed (it got to "ready for committer" since then).
I'm marking it as rejected. Unless someone has a compelling use case
for this feature that hasn't been put forward, I think we're done
I'm a bit torn - I think the protection might be useful, but there are a
few issues with this approach:
1) Getting the "can't start, WAL segments lost" message after a crash
is a bit late. It protects against silent data loss, it only makes
it "not silent" so it's not "fixed". But maybe it's worth it.
2) It protects against a fairly narrow class of failures when we lose
the last WAL segment for some reason. Hopefully once we add the
additional fsyncs that particular failure scenario will get fixed,
but the question is whether we're in danger of reintroducing it
(or a similar issue) later.
I guess we could mark it as "rejected" but that's likely to eliminate
any further feedback / discussion about the protection in general.
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Sent via pgsql-hackers mailing list (email@example.com)
To make changes to your subscription: