2011/1/11 Robert Haas <robertmh...@gmail.com>: > On Mon, Jan 10, 2011 at 1:17 PM, Josh Berkus <j...@agliodbs.com> wrote: >> I'm going to disagree here. For a large, sprawling, legacy application >> changing SERIALIZABLE to REPEATABLE READ in every place in the code >> which might call it can be prohibitively difficult. > > What makes you think that would be necessary? That'd require someone > (a) using serializable, and (b) wanting it to be broken? I think the > most common reaction would be "thank goodness, this thing actually > works now".
it works, but not works perfect. Some "important" toolkit like performance benchmarks doesn't work with PostgreSQL without failures. It's one reason why PostgreSQL has less score in some enterprise rating than MySQL. It working for current user, but it not works well for users who should do decision for migration to PostgreSQL. I don't see a problem in GUC, but it isn't a problem - more significant problem is current PostgreSQL's serializable implementation in general (that should work on more SQL servers) applications. It's a break for one class of customers. Regards Pavel Stehule > >> Further, many such >> applications would be written with workarounds for broken serializable >> behavior, workarounds which would behave unpredictably after an upgrade. > > Uh... you want to support that with an example? Because my first > reaction is "that's FUD". > > -- > Robert Haas > EnterpriseDB: http://www.enterprisedb.com > The Enterprise PostgreSQL Company > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers > -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
