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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
