Robert Haas <robertmh...@gmail.com> wrote: > Simon Riggs <si...@2ndquadrant.com> wrote: >> * throw a WARNING if serializable is stated in other cases, and >> downgrade the request to repeatable read > > I think this would be reasonable, but it's still my second choice. > The advantage of throwing an ERROR is that someone will presumably > be forced to realize that a problem exists and fix it, whereas a > WARNING may just generate a combination of log spam and unexpected > behavior forever. Also, we currently block cases where you try to > set transaction_isolation by throwing an ERROR, so it seems a bit > more consistent to do that in other cases as well. Still, it's a > reasonable choice, and certainly better than failing an assertion. I'm not totally clear on your first choice. Are you looking for something similar to the patch I posted, except that it would dodge all resulting errors at the point where they are promoted to FATAL (before HS is really functional)? -Kevin
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers