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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers