On 2016-05-03 11:58:34 -0400, Robert Haas wrote:
> - Atomic Pin/Unpin. There are two different open items related to
> this, both apparently relating to testing done by Jeff Janes. I am
> not sure whether they are really independent reports of different
> problems or just two reports of the same problem. But they sound like
> fairly serious breakage.
It's a bit hard to say, given the test take this long to run, but so far
I've a fair amount of doubt that the bug report is actually related to
the atomic pin/unpin. It appears to me - I'm in the process of trying
to confirm (again long runs) that the pin/unpin patch merely changed the
timing.
> - Checkpoint Sorting and Flushing. Andres tried to fix the last
> report of problems with this in
> 72a98a639574d2e25ed94652848555900c81a799, but there were almost
> immediately new reports.
Yea, it's an issue with the 72a98a639574d2e25ed94652848555900c81a799,
not checkpoint flushing itself. Turns out that mdsync() *wants/needs* to
access deleted segments. Easily enough fixed. I've posted a patch, which
I plan to commit unless somebody wants to give input on the flag design.
> There are a few other open items, but I would consider reverting the
> antecedent patches as either impractical or disproportionate in those
> cases. Aside from the two cases you mentioned, I don't think that
> anyone's actually called for these other patches to be reverted, but
> I'm not sure that we shouldn't be considering it. What do you (and
> others) think?
I'm *really* doubtful about the logical timeline following patches. I
think they're, as committed, over-complicated and pretty much unusable.
Greetings,
Andres Freund