Re: Disabled features on Hot Standby - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Disabled features on Hot Standby
Date
Msg-id CA+TgmobRWe8JT1KJEoQDBh402tKB963+xXmzptD4QHzyo=N0pg@mail.gmail.com
Whole thread Raw
In response to Re: Disabled features on Hot Standby  (Dimitri Fontaine <dimitri@2ndQuadrant.fr>)
List pgsql-hackers
On Sat, Jan 14, 2012 at 6:44 AM, Dimitri Fontaine
<dimitri@2ndquadrant.fr> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> With the exception of EXPLAIN
>> support which I think is merely an oversight, all of those issues,
>> including the problems in Hot Standby mode, remain because nobody
>> knows exactly what we ought to do to fix them.  When somebody figures
>> it out, I predict they'll get fixed pretty quickly.
>
> So this problem goes into the 9.2 Open Items list, right? It looks not
> tied to this particular commit fest. Also, with so many people involved,
> I think there shouldn't be any finger pointing here.

Well, I wouldn't personally be horrified if this didn't get fixed for
9.2, but since you and Simon and Noah seem to feel strongly about it,
I'm inclined to say we should go ahead and fix it, so sure.  Actually,
come to think of it, it really is on the open items list already: "fix
it so index-only scans work on the standby" is merely a more ambitious
version of "disable index-only scans on the standby", so it pretty
much works out to the same thing.

Furthermore, if we unconditionally generate recovery conflicts as
Simon is proposing, this sounds like it might be pretty darn simple.
I was in the midst of thinking about how to make the locking work if
we changed behavior when changing hot_standby_feedback, but if we
don't even need to go there so much the better.  I'm happy to accept
Simon/Noah's judgement that the rate of conflicts will be acceptable;
I haven't worked with Hot Standby enough myself to have an educated
opinion on that topic.

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


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Concurrent CREATE TABLE/DROP SCHEMA leaves inconsistent leftovers
Next
From: Robert Haas
Date:
Subject: Re: Command Triggers