Re: Re: synchronous_commit and synchronous_replication Re: [COMMITTERS] pgsql: Efficient transaction-controlled synchronous replication.

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Re: synchronous_commit and synchronous_replication Re: [COMMITTERS] pgsql: Efficient transaction-controlled synchronous replication.
Дата
Msg-id BANLkTimc91EEF74gisyAFB4cgZ-wBEvndA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Re: synchronous_commit and synchronous_replication Re: [COMMITTERS] pgsql: Efficient transaction-controlled synchronous replication.  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Re: synchronous_commit and synchronous_replication Re: [COMMITTERS] pgsql: Efficient transaction-controlled synchronous replication.  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
On Tue, Apr 5, 2011 at 11:12 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> "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.

Well, I posted a note about this on Thursday:

http://archives.postgresql.org/pgsql-hackers/2011-03/msg01930.php

I didn't feel strongly that it needed to be done, but there seemed to
be some support for doing it:

http://archives.postgresql.org/pgsql-hackers/2011-03/msg01940.php
http://archives.postgresql.org/pgsql-hackers/2011-03/msg01943.php

But I'm wondering whether that was really the right decision.  It
might have been better just to drop it, and I'll certainly back it out
if people feel that's more appropriate.

I am also wondering about the open issue of supporting comments to
SQL/MED objects.  I thought that was pretty straightforward, but given
that it took me three commits to get servers and foreign data wrappers
squared away and then it turned out that we're still missing support
for user mappings, I've been vividly reminded of the danger of
seemingly harmless commits.  Now I'm thinking that I should have just
replied to the initial report with "good point, but it's not a new
regression, so we'll fix it in 9.2".  But given that part of the work
has already been done, I'm not sure whether I should (a) finish it, so
we don't have to revisit this in 9.2, (b) leave it well enough alone,
and we'll finish it in 9.2, or (c) back out what's already been done
and plan to fix the whole thing in 9.2.

Everything else on the open items list appears to be a bona fide bug,
though the generate_series thing is not a new regression.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


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

Предыдущее
От: Jim Nasby
Дата:
Сообщение: Re: WIP: Allow SQL-language functions to reference parameters by parameter name
Следующее
От: Heikki Linnakangas
Дата:
Сообщение: Re: Transforming IN (...) to ORs, volatility