File:Synch rep patchset v4.tgz
From PostgreSQL wiki
Jump to navigationJump to searchSynch_rep_patchset_v4.tgz (file size: 108 KB, MIME type: application/x-gzip)
Warning: This file type may contain malicious code. By executing it, your system may be compromised.
File history
Click on a date/time to view the file as it appeared at that time.
| Date/Time | Dimensions | User | Comment | |
|---|---|---|---|---|
| current | 02:22, 28 November 2008 | (108 KB) | Masaofujii (talk | contribs) | Hello, Attached is the updated patch of Synch Rep (v4). I changed the patch according to the comment against v3 and fixed some bugs. http://archives.postgresql.org/pgsql-hackers/2008-11/msg01615.php List of updates -------------------- * Rename the database for replication from "walsender" to "replication". * Change the way to treat "replication" database so that the normal client can connect and query to it. So, in order to start replication, it's necessary to connect to "replication" database and send the particular message. * Disable skipping-WAL optimization during replication like WAL archiving. * Push RequestXLogSend and WaitXLogSend into XLogFlush to simplify the code. * Re-define replication_timeout as PGC_SUSET to prevent the non-superuser from stopping replication easily. * Change the logic to forbid the startup process from trying to redo the WAL which walreceiver has not received yet. This happens when the trigger file of pg_standby is created while walreceiver is alive. Before the startup process get over the WAL position where walreceiver has not reached at yet, walreceiver certainly exits. * Integrate the logic to start replication between walsender and walreceiver in order to simplify the code. * Change walsender and walreceiver to display the replication starting / ending position when replication starts / ends. * Skip recycling the restored WAL file if it's a symbolic link. * Re-zero the page if needed before walreceiver writes the WAL to disk. * Add new trigger file option into pg_standby, which can promote the standby to the primary without any transaction loss. http://archives.postgresql.org/pgsql-hackers/2008-11/msg01638.php I shelved the change for pg_standby to get over the gap of timeline this time, because the consensus is not reached. http://archives.postgresql.org/pgsql-hackers/2008-11/msg01612.php If you notice anything, please feel free to comment! Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center |
You cannot overwrite this file.
File usage
There are no pages that use this file.
