Greg Smith <[EMAIL PROTECTED]> writes: > As the person who was complaining about corner cases I'm not in a position > to talk more explicitly about, I can at least summarize my opinion of how > I feel everyone should be thinking about this patch and you can take what > you want from that.
Sorry, but we're not going to make decisions on the basis of evidence you won't show us. Right at the moment the best thing to do seems to be to enable LDC with a low minimum write rate and a high target duration, and remove the thereby-obsoleted "all buffers" scan of the existing bgwriter logic. If you've got specific evidence why any of these things need to be parameterized, let's see it. Personally I think that we have a bad track record of exposing GUC variables as a substitute for understanding performance issues at the start, and this approach isn't doing any favors for DBAs. > Whether or not I think this is an awesome idea, the very idea of a change > that big at this point gives me the willies. Just off the top of my head, > there's a whole class of issues involving recycling xlog segments this > would introduce I would be really unhappy with the implications of. Really? Name one. AFAICS this should not affect xlog recycling in the slightest (other than that we have to bump up the target number of live segments from 2x to 3x the checkpoint distance). > Did anyone else ever notice that when a new xlog segment is created, > the write to clear it out doesn't happen via direct I/O like the rest > of the xlog writes do? It's not supposed to matter, because that path isn't supposed to be taken often. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend