digoal@126.com wrote:
> digoal=3D# select * from heap_page_items(get_raw_page('test', 0));
> lp | lp_off | lp_flags | lp_len | t_xmin | t_xmax | t_field3 | t_ctid =
|
> t_infomask2 | t_infomask | t_hoff | t_bits | t_oid=20
> ----+--------+----------+--------+--------+--------+----------+--------=
+-------------+------------+--------+--------+-------
> 1 | 8160 | 1 | 28 | 1743 | 1744 | 0 | (0,1) =
| =20
> 1 | 448 | 24 | | =20
> t_infomask is 0x01c0
> in htup_detail.h it's
> #define HEAP_XMAX_EXCL_LOCK 0x0040 /* xmax is exclusive lo=
cker
> */
> #define HEAP_XMAX_LOCK_ONLY 0x0080 /* xmax, if valid, is o=
nly a
> locker */
>=20
> =
=20
> /* xmax is a shared locker */
> #define HEAP_XMAX_SHR_LOCK (HEAP_XMAX_EXCL_LOCK |
> HEAP_XMAX_KEYSHR_LOCK)
> #define HEAP_XMIN_COMMITTED 0x0100 /* t_xmin committed */
>=20
> SO, it get a HEAP_XMAX_SHR_LOCK lock. but the output of pgrowlocks is F=
OR
> UPDATE.
No, this is fine actually. Notice that XMAX_SHR_LOCK needs both
XMAX_EXCL_LOCK and XMAX_KEYSHR_LOCK. What 0xc0 has XMAX_EXCL_LOCK, but
not XMAX_KEYSHR_LOCK -- there's XMAX_LOCK_ONLY, which is different.
You're right that pgrowlocks is giving a bogus output here -- says For
Update, should say For No Key Update.
> And then i start another session ,i can get a key share lock. and then =
get
> the share lock.
> digoal=3D# begin;
> BEGIN
> digoal=3D# select * from test where id=3D1 for key share;
> id=20
> ----
> 1
> (1 row)
> -- this will fill the t_infomask's HEAP_XMAX_IS_MULTI bit. and then i =
can
> get a share lock .
> digoal=3D# select * from test where id=3D1 for share;
> id=20
> ----
> 1
> (1 row)
> but in correct rule, another session cann't get the share lock.
> It's a BUG?
Hm, yeah, this is a bug. Looking.
--=20
=C1lvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
