Re: Summary and Plan for Hot Standby

Stefan Kaltenbrunner <stefan@kaltenbrunner.cc>

From: Stefan Kaltenbrunner <stefan@kaltenbrunner.cc>
To: Simon Riggs <simon@2ndQuadrant.com>
Cc: Tatsuo Ishii <ishii@sraoss.co.jp>, heikki.linnakangas@enterprisedb.com, ishii@postgresql.org, pgsql-hackers@postgresql.org
Date: 2009-11-20T06:12:30Z
Lists: pgsql-hackers
Simon Riggs wrote:
> On Thu, 2009-11-19 at 17:15 +0900, Tatsuo Ishii wrote:
>>> Simon Riggs wrote:
>>>> Recovery does *not* take the same locks as the original statements on
>>>> the master took. For example, the WAL record for an INSERT just makes
>>>> its changes without acquiring locks. This is OK as long as we only allow
>>>> read-only users to acquire AccessShareLocks. If we allowed higher locks
>>>> we might need to do deadlock detection, which would add more complexity.
>>> But we *do* allow higher locks than AccessShareLocks, as Tatsuo-sans
>>> example shows. Is that a bug?
>> Sorry for confusion. My example is under normal PostgreSQL, not under
>> HS enabled.
> 
> Are you saying you want it to work in HS mode?
> 
> Why would you want to PREPARE an INSERT, but never execute it?

well I can easily imagine an application that keeps persistent 
connections and prepares all the queries it might execute after it does 
the initial connection yet being still aware of the master/slave setup.
So the scenario would be "prepare but never execute as long as we are in 
  recovery - but once we left recovery we can use them".

Stefan