tag:blogger.com,1999:blog-20038672.post1333052115698696027..comments2024-03-19T04:09:53.166-04:00Comments on Robert Haas: What Kind of Replication Do You Need?Robert Haashttp://www.blogger.com/profile/08393677427643988650noreply@blogger.comBlogger3125tag:blogger.com,1999:blog-20038672.post-27978895158230764972011-01-18T22:01:25.884-05:002011-01-18T22:01:25.884-05:00In my case I've got a basic tagging applicatio...In my case I've got a basic tagging application, with the provision that tags really can never be lost (financial transactions). The entire value of the app comes from durability. <br /><br />It's fine for a user to tag transactions twice, but once the user sees the green AJAX generated check mark the item needs to be solid. There's a bunch of other components with same requirement. Not ok to lose a green checkmark / transaction, but ok to fail (even frequently if needed). All OK to repeat in this case. <br /><br />For me, WAL received as the sync rep parameter is fine.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-20038672.post-30752483501887593672011-01-18T16:36:56.685-05:002011-01-18T16:36:56.685-05:00There are indeed several possible definitions of s...There are indeed several possible definitions of synchronous replication - WAL received, WAL fsync'd, WAL applied. Ultimately we should probably support all of them; but you're right that the discussion above focuses (too?) specifically on the "fsync" level. I'm not sure which version(s) Simon's patch supports - it's been discussed on the list a few times, but I'm not sure what the current state of the patch is. Using "WAL apply" mode to keep the slaves up to date with respect to the master is another valid use case for this feature.<br /><br />In terms of performance, your comments about throughput are correct to a degree, but not completely, since using more process slots slows down ProcArray manipulations and generally drags on system performance; and of course some applications are latency-sensitive.Robert Haashttps://www.blogger.com/profile/08393677427643988650noreply@blogger.comtag:blogger.com,1999:blog-20038672.post-63094415301209605982011-01-18T15:34:47.537-05:002011-01-18T15:34:47.537-05:00I haven't been following this closely. I alway...I haven't been following this closely. I always assumed that the main point of synchronous replication is that, by the time an application completes a COMMIT, all the data is also accessible on the slaves. IOW, that slaves don't return stale data, which is important for load balancing.<br /><br />But now I realize that this may not be true. If you define synchronous replication as "slave synced WAL to disk", it doesn't necessarily mean that it has <i>processed</i> the WAL yet?<br /><br />Also, you say that sync replication will result in a loss of performance. Sure, individual transactions will take longer, but aggregate <b>throughput</b> of the server shouldn't decrease significantly, because the backend has freed all its locks and is just sleeping -- or am I missing something?Marti Raudseppnoreply@blogger.com