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

On further review, I think (a) is not even an option worth discussing.The permissions-checking logic for user mappings
isquite different 
from what we do in the general case, and it seems likely to me that
cleaning this up is going to require far more time and thought than we
ought to be putting into what is really a relatively minor wart.  In
retrospect, it seems clear that this wasn't worth messing with in the
first place at this late date in the release cycle.

If there are any other items on the open items list that seem like
things we should not be worrying about right now, please point them
out.  I'm likely guilty of tunnel vision, as I have been heavily
focused on trying to make the list go to zero, and of course
committing stuff is only one of two possible ways to get them off the
list - the other is to decide that that they shouldn't have been added
in the first place.

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


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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Re: [COMMITTERS] pgsql: Support comments on FOREIGN DATA WRAPPER and SERVER objects.
Следующее
От: Jan Wieck
Дата:
Сообщение: Re: Reading from a REFCURSOR in a C language function