>>> Gregory Stark <stark(at)enterprisedb(dot)com> wrote:
> "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> writes:
>
>> PostgreSQL is much less prone to serialization failures, but it is
>> certainly understandable if hot standby replication introduces new
>> cases of it.
>
> In this case it will be possible to get this error even if you're
just
> running
> a single SELECT query -- and that's the *only* query in the database
at all.
>
> A vacuum being replayed -- even in a different database -- could
trigger the
> error. Or with the btree split issue, a data load -- again even in a
different
> database -- would be quite likely cause your SELECT to be killed.
OK. Does that make serialization failure a bad description of the
problem?
If these steps are serialized (run one after the other), is there a
problem? It just seems that the hot standby near-synchronous
replication creates a situation where tasks on multiple, linked
databases might need to be serialized.
It does seem like it will be important to provide as much information
to the user about what's causing the problem, and hints about what to
do. PostgreSQL has nice features for that, though.
Since I have no vested interest here, I'm not inclined to belabor the
point. I was really just trying to make sure the feature was as
useful as possible to others, some of whom might be looking for
standard SQLSTATE values to help the software take the right course.
If others feel the 40001 code would confuse more than enlighten, I'll
respect that.
-Kevin