>>> Gregory Stark <st...@enterprisedb.com> wrote: > "Kevin Grittner" <kevin.gritt...@wicourts.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
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
