On 2015-06-02 11:29:24 -0400, Robert Haas wrote: > On Tue, Jun 2, 2015 at 8:56 AM, Andres Freund <and...@anarazel.de> wrote: > > But what *definitely* looks wrong to me is that a TruncateMultiXact() in > > this scenario now (since a couple weeks ago) does a > > SimpleLruReadPage_ReadOnly() in the members slru via > > find_multixact_start(). That just won't work acceptably when we're not > > yet consistent. There very well could not be a valid members segment at > > that point? Am I missing something? > > Yes: that code isn't new.
Good point. > TruncateMultiXact() called SimpleLruReadPage_ReadOnly() directly in > 9.3.0 and every subsequent release until 9.3.7/9.4.2. But back then TruncateMultiXact() wasn't called during recovery. But you're right in that it didn't seem to have reproduced attributable bugreprorts since 9.3.2 where vacuuming during recovery was introduced. So it indeed doesn't seem as urgent as fixing the new callsites. > That would be a departure from the behavior of every existing release > that includes this code based on, to my knowledge, zero trouble > reports. On the other hand we're now at about bug #5 attributeable to the odd way truncation works for multixacts. It's obviously complex and hard to get right. It makes it harder to cope with the wrong values left in datminxid etc. So I'm still wondering whether fixing this for good isn't the better approach. 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
