Re: max_wal_senders must die
От | Simon Riggs |
---|---|
Тема | Re: max_wal_senders must die |
Дата | |
Msg-id | 1288166933.1587.1246.camel@ebony обсуждение исходный текст |
Ответ на | Re: max_wal_senders must die (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: max_wal_senders must die
|
Список | pgsql-hackers |
On Tue, 2010-10-19 at 15:32 -0400, Tom Lane wrote: > Robert Haas <robertmhaas@gmail.com> writes: > > On Tue, Oct 19, 2010 at 12:18 PM, Josh Berkus <josh@agliodbs.com> wrote: > >> On 10/19/2010 09:06 AM, Greg Smith wrote: > >>> I think Magnus's idea to bump the default to 5 triages the worst of the > >>> annoyance here, without dropping the feature (which has uses) or waiting > >>> for new development to complete. > > > Setting max_wal_senders to a non-zero value causes additional work to > > be done every time a transaction commits, aborts, or is prepared. > > Yes. Sorry guys, but that is completely wrong. There is no additional work to be done each time a transaction commits, even with sync rep. And I don't mean "nearly zero", I mean nada. > This isn't just a numeric parameter; it's also a boolean > indicating "do I want to pay the overhead to be prepared to be a > replication master?". Agreed, but its to do with wal_level. > Josh has completely failed to make a case that > that should be the default. Agreed. > In fact, the system would fail to start > at all if we just changed the default for max_wal_senders and not the > default for wal_level. Agree with that as a problem. -- Simon Riggs http://www.2ndQuadrant.com/books/PostgreSQL Development, 24x7 Support, Training and Services
В списке pgsql-hackers по дате отправления: