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