On 5/29/08, Aidan Van Dyk <[EMAIL PROTECTED]> wrote: > * Dave Page <[EMAIL PROTECTED]> [080529 12:03]: > > On Thu, May 29, 2008 at 4:48 PM, Douglas McNaught <[EMAIL PROTECTED]> 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
