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
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 |