| From: | Josh Berkus <josh(at)agliodbs(dot)com> |
|---|---|
| To: | Bruce Momjian <bruce(at)momjian(dot)us> |
| Cc: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Andres Freund <andres(at)2ndquadrant(dot)com>, Tomonari Katsumata <t(dot)katsumata1122(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Tomonari Katsumata <katsumata(dot)tomonari(at)po(dot)ntts(dot)co(dot)jp>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Should we remove "not fast" promotion at all? |
| Date: | 2013-08-08 17:15:14 |
| Message-ID: | 5203D222.6060505@agliodbs.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Bruce, all:
> We seem to be all over the map with the fast promotion code --- some
> people don't trust it, some people want an option to enable the old
> method, and some people want the old method removed.
Having read over this thread, the only reason given for retaining any
ability to use "old" promotion code is because people are worried about
"fast" promotion being buggy. This seems wrong.
Either we have confidence is fast promotion, or we don't. If we don't
have confidence, then either (a) more testing is needed, or (b) it
shouldn't be the default. Again, here, we are coming up against our
lack of any kind of broad replication failure testing.
Of course, even if we have confidence, bugs are always possible, and
leaving the old promotion code in there would make it somewhat easier to
ship a 9.3.2 update which reverts the behavior. But maybe we should
focus on shipping a version which is relatively bug-free instead?
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2013-08-08 17:28:47 | Re: mvcc catalo gsnapshots and TopTransactionContext |
| Previous Message | Andres Freund | 2013-08-08 16:57:51 | Re: Should we remove "not fast" promotion at all? |