On 5/29/08, Aidan Van Dyk <aidan@highrise.ca> wrote:
> * Dave Page <dpage@pgadmin.org> [080529 12:03]:
> > On Thu, May 29, 2008 at 4:48 PM, Douglas McNaught <doug@mcnaught.org> wrote:
> > > I think the idea is that WAL records would be shipped (possibly via
> > > socket) and applied as they're generated, rather than on a
> > > file-by-file basis. At least that's what "real-time" implies to me...
> >
> > Yes, we're talking real-time streaming (synchronous) log shipping.
>
> But synchronous streaming doesn't mean the WAL has to be *applied* on
> the salve yet. Just that it has to be "safely" on the slave (i.e on
> disk, not just in kernel buffers).
>
> The whole single-threaded WAL replay problem is going to rear it's ugly
> head here too, and mean that a slave *won't* be able to keep up with a
> busy master if it's actually trying to apply all the changes in
> real-time. Well, actually, if it's synchronous, it will keep up, but it
> just means that now your master is IO capabilities is limited to the
> speed of the slaves single-threaded WAL application.
I don't think thats a problem. If the user runs its server at the
limit of write-bandwidth, thats its problem.
IOW, with synchronous replication, we _want_ the server to lag behind
slaves.
About the single-threading problem - afaik, the replay is mostly I/O bound
so threading would not buy you much.
--
marko