Peter Eisentraut <peter_e(at)gmx(dot)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