| From: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com> |
|---|---|
| To: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | New trigger option of pg_standby |
| Date: | 2009-03-25 06:29:21 |
| Message-ID: | 3f0b79eb0903242329j12865d55s348f5c873a956e71@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
Current pg_standby is dangerous because the presence of the trigger
file causes recovery to end whether or not the next WAL file is available.
So, some *available* transactions may be lost at failover. Such danger
will become high if the standby server has not caught up with the primary.
Attached patch fixes the above problem by adding a new trigger option
to pg_standby; the presence of this new trigger file causes recovery to
end after replaying all the available WAL files. Specifically, pg_standby
acts like 'cp' or 'ln' command while this new trigger file exists.
I've not changed any existing features, so backward-compatibility is
maintained.
Thought?
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
| Attachment | Content-Type | Size |
|---|---|---|
| pgstandby_new_trigger_0325.patch | application/octet-stream | 16.5 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Guillaume Smet | 2009-03-25 06:50:04 | Re: New trigger option of pg_standby |
| Previous Message | Greg Smith | 2009-03-25 03:23:36 | Re: improving concurrent transactin commit rate |