Re: Summary and Plan for Hot Standby

From: Stefan Kaltenbrunner <stefan(at)kaltenbrunner(dot)cc>
To: Simon Riggs <simon(at)2ndQuadrant(dot)com>
Cc: Tatsuo Ishii <ishii(at)sraoss(dot)co(dot)jp>, heikki(dot)linnakangas(at)enterprisedb(dot)com, ishii(at)postgresql(dot)org, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Summary and Plan for Hot Standby
Date: 2009-11-20 06:12:30
Message-ID: 4B06334E.7070402@kaltenbrunner.cc
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2009-11-20 06:12:38 Re: Why do OLD and NEW have special internal names?
Previous Message Peter Eisentraut 2009-11-20 06:04:43 Re: Python 3.1 support