Re: Re: synchronous_commit and synchronous_replication Re: [COMMITTERS] pgsql: Efficient transaction-controlled synchronous replication.
От | Tom Lane |
---|---|
Тема | Re: Re: synchronous_commit and synchronous_replication Re: [COMMITTERS] pgsql: Efficient transaction-controlled synchronous replication. |
Дата | |
Msg-id | 3283.1302016348@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Re: synchronous_commit and synchronous_replication Re: [COMMITTERS] pgsql: Efficient transaction-controlled synchronous replication. ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>) |
Ответы |
Re: Re: synchronous_commit and synchronous_replication Re:
[COMMITTERS] pgsql: Efficient transaction-controlled synchronous replication.
|
Список | pgsql-hackers |
"Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes: > Robert Haas <robertmhaas@gmail.com> wrote: >> Dimitri Fontaine <dimitri@2ndquadrant.fr> wrote: >>> Maybe it's just me, but I'm struggling to understand current >>> community processes and decisions. >> Well, I've already spent a fair amount of time trying to explain >> my understanding of it, and for my trouble I got accused of being >> long-winded. Which is probably true, but makes me think I should >> probably keep this response short. I'm not unwilling to talk >> about it, though, and perhaps someone else would like to chime in. > I rather liked the brief comment in a recent post of yours where you > said that at this point we should only be accepting patches which > stabilize what has already been committed, rather than new features > which might require further stabilization. Quite. While we're on the subject, why did that int->money patch get committed so quickly? I had assumed that was 9.2 material, because it didn't seem to be addressing any new-in-9.1 issue. I'm not going to ask for it to be backed out, but I am wondering what the decision process was. regards, tom lane
В списке pgsql-hackers по дате отправления: