Peter Eisentraut <pete...@gmx.net> wrote: > Some of these new error messages from the SSI code are a mouthful: > > not enough elements in RWConflictPool to record a rw-conflict > not enough elements in RWConflictPool to record a potential > rw-conflict > > These are basically "out of shared memory" conditions that could > be moved to a DETAIL message. Yes and no. The resource which is exhausted at this point *is* in shared memory, but its allocation of space is fixed at startup -- it's not competing with other users of shared memory for the shared memory "slush space". I have some concern that an "out of shared memory" message might confuse people on that aspect of the issue. That said, if people find it helps more than it hurts, I have no objection to a wording change. > Canceled on identification as a pivot, during conflict out > checking. > Canceled on conflict out to old pivot %u. > Canceled on identification as a pivot, with conflict out to > old committed transaction %u. > Canceled on conflict out to old pivot. > Canceled on identification as a pivot, during conflict in > checking. > Canceled on identification as a pivot, during write. > Canceled on conflict out to pivot %u, during read. > Canceled on identification as a pivot, during commit attempt. > Canceled on commit attempt with conflict in from prepared > pivot. > > These are DETAIL messages, with the rest of the report saying > > ERROR: could not serialize access due to read/write > dependencies among transactions > HINT: The transaction might succeed if retried. > > AFAICT, the documentation doesn't mention anything about this > "pivot" that keeps coming up. Good point. It's in the README-SSI and the Wiki page, but not in the user docs; so using it in the error detail seems likely to confuse. Also, some of the information is referring to phases of processing which can only be understood by looking at the source code, like "during conflict out checking." While it might not be entirely unreasonable to document what a pivot is, documenting some of the other language is really out of the question. > Is it useful that have the user face this information? Is there > anything a user can derive from seeing one of these messages > versus another, and in addition to the error and hint, that would > help them address the situation? A user with a firm grasp of SSI might be better able to figure out mitigation techniques for frequently occurring rollback scenarios with that detail. We did have one thread where someone was hoping for as much information as we could provide, but I don't know how typical that will be: http://archives.postgresql.org/pgsql-hackers/2010-09/msg01133.php I find the differentiation of causes helpful when working through test cases, but moving this information to DEBUG messages might satisfy that need. I've also wondered whether that HINT line is worthwhile. I have a suspicion that we might sometimes find the information conveyed by the detail useful when responding to users with questions; but the language as it stands seems confusing for users. -Kevin
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
