Re: recovery_connections cannot start (was Re: master in standby mode croaks)
От | Robert Haas |
---|---|
Тема | Re: recovery_connections cannot start (was Re: master in standby mode croaks) |
Дата | |
Msg-id | r2t603c8f071004231045qffc80962ld495cb5aa9a67bde@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: recovery_connections cannot start (was Re: master in standby mode croaks) (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: recovery_connections cannot start (was Re: master in standby mode croaks)
Re: recovery_connections cannot start (was Re: master in standby mode croaks) |
Список | pgsql-hackers |
On Fri, Apr 23, 2010 at 12:09 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas@gmail.com> writes: >> On Fri, Apr 23, 2010 at 7:12 AM, Heikki Linnakangas >> <heikki.linnakangas@enterprisedb.com> wrote: >>> Streaming replication needs the same information in the WAL as archiving >>> does, > >> True. > > FWIW, I still don't believe that claim, and I think it's complete folly > to set the assumption in stone by choosing a user-visible GUC API that > depends on it being true. Huh? We're clearly talking about two different things here, because that doesn't make any sense. Archiving and streaming replication are just two means of transporting WAL records from point A to point B. By definition, any two manners of moving a byte stream around are isomorphic and can't possibly affect what that byte stream does or does not need to contain. What affects the WAL that must be emitted is the purpose for which it is to be used. As to that, I believe everyone (including the code) is in agreement that a minimum amount of WAL is always needed for crash recovery, plus if we want to do archive recovery on another server there are some additional bits that must be emitted (XLogIsNeeded) and plus if further want to process queries on the standby then there are a few more bits beyond that (XLogStandbyInfoActive). ...Robert
В списке pgsql-hackers по дате отправления: