| From: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
|---|---|
| To: | Tatsuo Ishii <ishii(at)sraoss(dot)co(dot)jp> |
| Cc: | 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-19 09:00:05 |
| Message-ID: | 1258621205.27757.976.camel@ebony |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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?
--
Simon Riggs www.2ndQuadrant.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Eisentraut | 2009-11-19 10:05:42 | Re: Python 3.1 support |
| Previous Message | Heikki Linnakangas | 2009-11-19 08:59:33 | Re: Summary and Plan for Hot Standby |