Re: Remaining Streaming Replication Open Items
От | Robert Haas |
---|---|
Тема | Re: Remaining Streaming Replication Open Items |
Дата | |
Msg-id | u2m603c8f071004131733vbda495d1rb77979416ecb1195@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Remaining Streaming Replication Open Items (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>) |
Ответы |
Re: Remaining Streaming Replication Open Items
|
Список | pgsql-hackers |
On Tue, Apr 13, 2010 at 11:49 AM, Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> wrote: > Robert Haas wrote: >> On Tue, Apr 6, 2010 at 10:36 AM, Heikki Linnakangas >> <heikki.linnakangas@enterprisedb.com> wrote: >>> Robert Haas wrote: >>>>>> * If standby_mode is enabled, and neither primary_conninfo nor restore_command are set, the standby would getstuck. >>>>> 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. > > We have the emode_for_corrupt_record() function that's used in all the > errors that indicate a corrupt WAL record, that's a perfect place to > hook this into. See attached patch. The test for elog == LOG seems a bit fragile to me - why that specifically? Maybe elog < PANIC? elog > DEBUG1? Both? But it seems basically sensible to me. ...Robert
В списке pgsql-hackers по дате отправления: