On Sat, May 8, 2010 at 6:51 PM, Bruce Momjian <br...@momjian.us> wrote: > Robert Haas wrote: >> On Sat, May 8, 2010 at 3:40 PM, Bruce Momjian <br...@momjian.us> wrote: >> > Robert Haas wrote: >> >> On Sat, May 8, 2010 at 2:48 PM, Bruce Momjian <br...@momjian.us> wrote: >> >> > I think the concensus is to change this setting to a boolean. ?If you >> >> > don't want to do it, I am sure we can find someone who will. >> >> >> >> I still think we should revert to Tom's original proposal. >> > >> > And Tom's proposal was to do it on WAL slave arrival time? ?If we could >> > get agreement from everyone that that is the proper direction, fine, but >> > I am hearing things like plugins, and other complexity that makes it >> > seem we are not getting closer to an agreed solution, and without >> > agreement, the simplest approach seems to be just to remove the part we >> > can't agree upon. >> > >> > I think the big question is whether this issue is significant enough >> > that we should ignore our policy of no feature design during beta. >> >> Tom's proposal was basically to define recovery_process_lock_timeout. >> The recovery process would wait X seconds for a lock, then kill >> whoever held it. It's not the greatest knob in the world for the >> reasons already pointed out, but I think it's still better than a >> boolean and will be useful to some users. And it's pretty simple. > > I thought there was concern about lock stacking causing > unpredictable/unbounded delays. I am not sure boolean has a majority > vote, but I am suggesting that because it is the _minimal_ feature set, > and when we can't agree during beta, the minimal feature set seems like > the best choice. > > Clearly, anything is more feature-full than boolean --- the big question > is whether Tom's proposal is significantly better than boolean that we > should spend the time designing and implementing it, with the > possibility it will all be changed in 9.1.
I doubt it's likely to be thrown out completely. We might decide to fine-tune it in some way. My fear is that if we ship this with only a boolean, we're shipping crippleware. If that fear turns out to be unfounded, I will of course be happy, but that's my concern, and I don't believe that it's entirely unfounded. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers