Re: Additional options for Sync Replication
| От | Simon Riggs |
|---|---|
| Тема | Re: Additional options for Sync Replication |
| Дата | |
| Msg-id | AANLkTinFqZn1K_vzBM7u_VLMp4dMdHP2FF0yJj_dYEus@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Additional options for Sync Replication (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>) |
| Ответы |
Re: Additional options for Sync Replication
|
| Список | pgsql-hackers |
On Mon, Mar 28, 2011 at 12:05 PM, Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> wrote: > On 28.03.2011 13:14, Simon Riggs wrote: >> >> On Mon, Mar 28, 2011 at 10:52 AM, Simon Riggs<simon@2ndquadrant.com> >> wrote: >>> >>> You have no basis on which to prevent this. >> >> It's also already on the Open Items list, put there by you. >> >> Why is this even a discussion point? > > FWIW, I agree this is an additional feature that we shouldn't be messing > with at this point in the release cycle. There is an open item about what the UI is for sync commit/sync rep, which is the subject of this patch. > The 'apply' mode would be quite interesting, it would make it easier to > build load-balancing clusters. But the patch isn't up to the task on that > yet - the 'apply' status report is only sent after > wal_receiver_status_interval fills up, so you get long delays. Yes it's up to the task, you misread it. It will continue sending replies while apply <> flush and then it will fall back to the behaviour you mention. > PS. you're missing some break's in the switch-statement in > SyncRepWaitForLSN(), effectively making the patch do nothing. OK, thanks. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: