Re: master in standby mode croaks
От | Robert Haas |
---|---|
Тема | Re: master in standby mode croaks |
Дата | |
Msg-id | v2m603c8f071004191458o94f5dd2ftb7b56b1f1e3fda6d@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: master in standby mode croaks (Fujii Masao <masao.fujii@gmail.com>) |
Список | pgsql-hackers |
On Mon, Apr 19, 2010 at 5:31 AM, Fujii Masao <masao.fujii@gmail.com> wrote: > On Mon, Apr 19, 2010 at 11:04 AM, Robert Haas <robertmhaas@gmail.com> wrote: >>> First of all, I wonder why the latter two need to affect the decision of >>> whether additional information is written to WAL for HS. How about just >>> removing XLogIsNeeded() condition from XLogStandbyInfoActive()? >> >> Bad idea, I think. If XLogIsNeeded() is returning false and >> XLogStandbyInfoActive() is returning true, the resulting WAL will >> still be unusable for HS, at least AIUI. > > Probably No. Such a WAL will be usable for HS unless an unlogged > operation (e.g., CLUSTER, CREATE TABLE AS SELECT, etc) happens. > I think that the occurrence of an unlogged operation rather than > XLogIsNeeded() itself must be checked in the standby, it's already > been being checked. So just removing XLogIsNeeded() condition makes > sense to me. I think that's a bad idea. Currently we have three possible types of WAL-logging: - just enough for crash recovery (archive_mode=off and max_wal_senders=0) - enough for log-shipping replication (archive_mode=on or max_wal_senders>0, but recovery_connections=off) - enough for log-shipping replication + hot standby (archive_mode=on or max_wal_senders>0, plus recovery_connections=on) I'm not eager to add a fourth category where hot standby works unless you do any of the things that break log-streaming in general. That seems hopelessly fragile and also fairly pointless. ...Robert
В списке pgsql-hackers по дате отправления: