Re: Remaining Streaming Replication Open Items
От | Robert Haas |
---|---|
Тема | Re: Remaining Streaming Replication Open Items |
Дата | |
Msg-id | t2k603c8f071004060806pf763abdby2c9dd3b9a4553baf@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Remaining Streaming Replication Open Items (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>) |
Ответы |
Re: Remaining Streaming Replication Open Items
Re: Remaining Streaming Replication Open Items |
Список | pgsql-hackers |
On Tue, Apr 6, 2010 at 10:36 AM, Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> wrote: > Robert Haas wrote: >> On Tue, Apr 6, 2010 at 3:09 AM, Heikki Linnakangas >> <heikki.linnakangas@enterprisedb.com> wrote: >>>> * Add the GUC parameter to specify the maximum number of log file segments held in pg_xlog directory to send tothe standby server. Which is useful to avoid disk full in the primary. >>> Not only to avoid disk full in primary but also to make it feasible to >>> use streaming replication without archiving. It's a small change, we >>> should do it. >> >> Do we have a working patch? > > No. :-( >>>> * Redefine smart shutdown in standby mode? >>> Drop. Too big a change at this point. >> >> We have a working patch for this - I want to commit it. I don't think >> it's a big change, and the current behavior is extremely pathological. > > Oh, ok. I didn't look at the latest patch, if it looks good to you, fine > with me. I'll commit it tonight. >>>> * If standby_mode is enabled, and neither primary_conninfo nor restore_command are set, the standby would get stuck. >>> It's not really stuck, it will replay any WAL files you drop into >>> pg_xlog. I concur with Robert Haas though that it shouldn't print the >>> message to the log every few seconds. It should print a message the >>> first time it hits the end of WAL, but subsequent messages should be >>> suppressed until some progress has been made. >> >> Any idea how to implement this? > > I'll take a look. It shouldn't be too hard. The tricky part, I believe, is that there's more than one message that can potentially be emitted, and you don't want ANY of them to repeat every 2 s, so some thought needs to be given to where to hook in the logic. ...Robert
В списке pgsql-hackers по дате отправления: