Synchronous replication patch v4

From: "Fujii Masao" <masao(dot)fujii(at)gmail(dot)com>
To: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Synchronous replication patch v4
Date: 2008-11-28 02:45:19
Message-ID: 3f0b79eb0811271845l4a8e4a20ga519aefc2a4d5162@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hello,

I chaged the patch accoding to the comment against v3 and fixed
some bugs. Since I failed to post the patch because of the excess
of mail size, I would attach it to Wiki from this time.
http://wiki.postgresql.org/wiki/NTT%27s_Development_Projects#Patch_set

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

Browse pgsql-hackers by date

  From Date Subject
Next Message Fujii Masao 2008-11-28 03:27:02 Re: Comments to Synchronous replication patch v3
Previous Message Alvaro Herrera 2008-11-28 00:22:35 Re: [PATCHES] GIN improvements