BUG #7840: PostgreSQL 9.3 devel select for no key share lock bug?

[d***@126.com]

The following bug has been logged on the website:

Bug reference: 7840
Logged by: digoal
Email address: ***@126.com
PostgreSQL version: Unsupported/Unknown
Operating system: CentOS 5.7 x64
Description:

I think there is a bug in PostgreSQL 9.3 devel version about select for no
key update.
there is no bitmask store for no key update info in tuple head.
and when i get a no key update lock, then i use pageinspect to see the
t_infomask. it's a shared lock bitmask.
like this :
digoal=# begin;
BEGIN
digoal=# select * from test where id=1 for no key update;
id
----
1
(1 row)
digoal=# 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
----+--------+----------+--------+--------+--------+----------+--------+-------------+------------+--------+--------+-------
1 | 8160 | 1 | 28 | 1743 | 1744 | 0 | (0,1) |
1 | 448 | 24 | |
t_infomask is 0x01c0
in htup_detail.h it's
#define HEAP_XMAX_EXCL_LOCK 0x0040 /* xmax is exclusive locker
*/
#define HEAP_XMAX_LOCK_ONLY 0x0080 /* xmax, if valid, is only a
locker */


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

SO, it get a HEAP_XMAX_SHR_LOCK lock. but the output of pgrowlocks is FOR
UPDATE.
digoal=# begin;
BEGIN
digoal=# select * from test where id=1 for key share;
id
----
1
(1 row)

digoal=# select * from test where id=1 for share;
id
----
1
(1 row)

And then i start another session ,i can get a key share lock. and then get
the share lock.
digoal=# begin;
BEGIN
digoal=# select * from test where id=1 for key share;
id
----
1
(1 row)
-- this will fill the t_infomask's HEAP_XMAX_IS_MULTI bit. and then i can
get a share lock .
digoal=# select * from test where id=1 for share;
id
----
1
(1 row)
but in correct rule, another session cann't get the share lock.
It's a BUG?

[Alvaro Herrera]

Post by d***@126.com
digoal=# 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
----+--------+----------+--------+--------+--------+----------+--------+-------------+------------+--------+--------+-------
1 | 8160 | 1 | 28 | 1743 | 1744 | 0 | (0,1) |
1 | 448 | 24 | |
t_infomask is 0x01c0
in htup_detail.h it's
#define HEAP_XMAX_EXCL_LOCK 0x0040 /* xmax is exclusive locker
*/
#define HEAP_XMAX_LOCK_ONLY 0x0080 /* xmax, if valid, is only a
locker */
/* 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 */
SO, it get a HEAP_XMAX_SHR_LOCK lock. but the output of pgrowlocks is FOR
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.

Post by d***@126.com
And then i start another session ,i can get a key share lock. and then get
the share lock.
digoal=# begin;
BEGIN
digoal=# select * from test where id=1 for key share;
id
----
1
(1 row)
-- this will fill the t_infomask's HEAP_XMAX_IS_MULTI bit. and then i can
get a share lock .
digoal=# select * from test where id=1 for share;
id
----
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.

[Alvaro Herrera]

Post by d***@126.com
Bug reference: 7840
Logged by: digoal
PostgreSQL version: Unsupported/Unknown
Operating system: CentOS 5.7 x64

I have pushed patches for these two problems, please give it a spin.
Thanks for testing.