Re: Re: [COMMITTERS] pgsql: Make a hard state change from catchup to streaming mode.

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Re: [COMMITTERS] pgsql: Make a hard state change from catchup to streaming mode.
Date: 2011-02-18 17:03:11
Message-ID: AANLkTikinhf5ntfUdwm1wLAq8xZ8+7geW9UCAoApO3aU@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

On Fri, Feb 18, 2011 at 10:56 AM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> We need a hard state change at one particular point to avoid sync rep
> requestors from hanging for hours when the standby is connected but a
> long way from being caught up.

That's a matter of opinion. I think there are a number of people here
who would say that what you need is a good way to know when you've
caught up, and that you shouldn't enable sync rep until that happens.
What you're proposing would be useful too, if it didn't break other
cases, but it does. This is precisely why it's a bad idea for us to
be trying to do this kind of engineering at the very last minute.

> This was a part of my sync rep patch that it was easier to break out and
> commit early. There has never been any comment or objection to this
> concept and the same feature has existed in my patches for months.

You posted the latest version of your sync rep patch on January 15th,
after months of inactivity. Heikki reviewed it on the 21st, and there
it sat un-updated for three weeks. If your expectation is that any
portion of that patch to which nobody specifically objected is fair
game to commit without further discussion, I don't think that's the
way it works around here.

Post your patches and we'll review them.

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

In response to

Browse pgsql-committers by date

  From Date Subject
Next Message Tom Lane 2011-02-18 18:12:04 pgsql: Fix parallel pg_restore to handle comments on POST_DATA items co
Previous Message Tom Lane 2011-02-18 16:56:31 pgsql: One more hack to make contrib upgrades from 9.0 match fresh 9.1

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2011-02-18 17:04:07 Re: contrib loose ends: 9.0 to 9.1 incompatibilities
Previous Message Tom Lane 2011-02-18 17:01:53 Re: contrib loose ends: 9.0 to 9.1 incompatibilities