I'm speccing up a three-node database for reliability, making use of streaming replication, and it's all working but I have a bit of a performance concern. Suppose a node dies and is removed from the cluster, but then returns (say, a day or two later). I could, of course, utterly wipe the existing data on that node and take a fresh copy from the master, but that would entail transferring the entire content of the database. The recommended option appears to be rsync, which saves on network traffic, but still has to read and hash every byte of data. Can the individual files' modification timestamps be relied upon? If so, it'd potentially mean a lot of savings, as the directory entries can be read fairly efficiently. I could still then use rsync to transfer those files (so if it's only a small part that's changed, we take advantage of its optimizations too). This may be digging too deep into the internals to be dependable for future versions. If so, I'd rather put the extra load on the servers than risk a future upgrade breaking replication subtly. Chris Angelico -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
