Re: recovery_connections cannot start (was Re: master in standby mode croaks)

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: recovery_connections cannot start (was Re: master in standby mode croaks)
Дата
Msg-id 18644.1272062554@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: recovery_connections cannot start (was Re: master in standby mode croaks)  (Simon Riggs <simon@2ndQuadrant.com>)
Список pgsql-hackers
Simon Riggs <simon@2ndQuadrant.com> writes:
> In my understanding this means that archive_mode does completely and the
> max_wal_senders does not affect WAL contents?

I think we'd concluded that we have to keep archive_mode as a separate
boolean.  (Or we could use Heikki's idea of a max number of unarchived
segments to hold onto, but I maintain that there are only two useful
values and so we might as well leave it as the existing boolean.)

> Does that mean that wal_mode can be SIGHUP now? It would be good. I
> think this is how to do that: 
> At the start of every WAL-avoiding operation we could take a copy of
> wal_mode for the server and store in MyProc->wal_mode. At transaction
> start we would set that to "not set". We could then make
> pg_start_backup() wait for all transactions with wal_mode set to
> complete before we continue.

I think that there are probably more synchronization issues than that,
and in any case now is not the time to be trying to implement that
feature.  Maybe we can make it work in 9.1.
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: recovery_connections cannot start (was Re: master in standby mode croaks)
Следующее
От: Simon Riggs
Дата:
Сообщение: Re: testing HS/SR - 1 vs 2 performance