| From: | Alexander Björnhagen <alex(dot)bjornhagen(at)gmail(dot)com> |
|---|---|
| To: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com> |
| Cc: | Aidan Van Dyk <aidan(at)highrise(dot)ca>, Robert Haas <robertmhaas(at)gmail(dot)com>, Magnus Hagander <magnus(at)hagander(dot)net>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Standalone synchronous master |
| Date: | 2012-01-13 10:30:40 |
| Message-ID: | CAO-C5=k1AB1Md3_cAS6zKZW54sOWcMkzqveyvCLg7EHZJadO4Q@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
At this point I feel that this new functionality might be a bit
overkill for postgres, maybe it's better to stay lean and mean rather
than add a controversial feature like this.
I also agree that a more general replication timeout variable would be
more useful to a larger audience but that would in my view add more
complexity to the replication code which is quite simple and
understandable right now ...
Anyway, my backup plan was to achieve the same thing by triggering on
the logging produced on the primary server and switch to async mode
when detecting that the standby replication link has failed (and then
back again when it is restored). In effect I would put a replication
monitor on the outside of the server instead of embedding it.
/A
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Marc Mamin | 2012-01-13 10:56:31 | CLONE TABLE DATA TO <new_table> |
| Previous Message | Fujii Masao | 2012-01-13 10:04:49 | replay_location indicates incorrect location |