* Greg Smith <gsmith@gregsmith.com> [090109 18:39]:
> I was hoping it might fall out of the other work being done in that area,
> given how much that code is still being poked at right now. As Hannu
> pointed out, from a conceptual level you just need to carry along the
> same information that pg_current_xlog_location() returns to the archiver
> on all the paths where a segment might end early.
I was(am) also hoping that somethig falls out of sync-rep that gives me
better PITR backups (better than a small archive_timeout)... That hope
is what made me abandon this patch after the initial feedback.
> Rather than creating a whole new GUC, it might it be possible to turn
> archive_mode into an enum setting: off, on, and cleaned as the modes
> perhaps. That would avoid making a new setting, with the downside that a
> bunch of critical code would look less clear than it does with a boolean.
I'm content to wait and see what falls out of sync-rep stuff...
... for now ...
> I understand the case you've made for why it doesn't matter, and for
> almost every case you're right. The situation it may be vulnerable to is
> where a burst of transactions come in just as the archive timeout expires
> after minimal WAL activity. There I think you can end up with a bunch of
> clients waiting behind an almost full zero fill operation, which pushes
> up the worst-case latency. I've been able to measure the impact of the
> similar case where zero-filling a brand new segment can impact things;
> this would be much less like to happen because the timing would have to
> line up just wrong, but I think it's still possible.
Ya, and it's one of just many of the times PG hits these worst-latency
spikes ;-) GEnerally, it's *very* good... and once in a while, when all
the stars line up correctly, you get these spikes....
But even with these spikes, it's plenty fast enough for the stuff I've
done...
a.
--
Aidan Van Dyk Create like a god,
aidan@highrise.ca command like a king,
http://www.highrise.ca/ work like a slave.
