Re: Summary and Plan for Hot Standby

From: Tatsuo Ishii <ishii(at)postgresql(dot)org>
To: simon(at)2ndquadrant(dot)com
Cc: pgsql-hackers(at)postgresql(dot)org, heikki(dot)linnakangas(at)enterprisedb(dot)com
Subject: Re: Summary and Plan for Hot Standby
Date: 2009-11-17 00:25:40
Message-ID: 20091117.092540.74752205.t-ishii@sraoss.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> > Please correct me if I'm wrong. Parse will result in obtaining
> > RowExclusiveLock on the target table if it is parsing
> > INSERT/UPDATE/DELETE. If so, is this ok in the standby?
>
> Any attempt to take RowExclusiveLock will fail.
>
> Any attempt to execute INSERT/UPDATE/DELETE will fail.
>
> This behaviour should be identical to read only transaction mode. If it
> is not documented as an exception, please report as a bug.

Is it?

It seems read only transaction mode is perfectly happy with
RowExclusiveLock:

test=# begin;
BEGIN
test=# set transaction read only;
SET
test=# prepare a(int) as insert into t1 values($1);
PREPARE
test=# \x
Expanded display is on.
test=# select * from pg_locks;
-[ RECORD 1 ]------+-----------------
locktype | relation
database | 1297143
relation | 10969
page |
tuple |
virtualxid |
transactionid |
classid |
objid |
objsubid |
virtualtransaction | 1/101699
pid | 28020
mode | AccessShareLock
granted | t
-[ RECORD 2 ]------+-----------------
locktype | virtualxid
database |
relation |
page |
tuple |
virtualxid | 1/101699
transactionid |
classid |
objid |
objsubid |
virtualtransaction | 1/101699
pid | 28020
mode | ExclusiveLock
granted | t
-[ RECORD 3 ]------+-----------------
locktype | relation
database | 1297143
relation | 1574918
page |
tuple |
virtualxid |
transactionid |
classid |
objid |
objsubid |
virtualtransaction | 1/101699
pid | 28020
mode | RowExclusiveLock
granted | t

test=# select relname from pg_class where oid = 1574918;
-[ RECORD 1 ]
relname | t1
--
Tatsuo Ishii
SRA OSS, Inc. Japan

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Itagaki Takahiro 2009-11-17 00:31:51 Re: UTF8 with BOM support in psql
Previous Message Andrew Dunstan 2009-11-17 00:15:05 Re: next CommitFest