Postgres Pro
Downloads
Home   >   mailing lists

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

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

From
digoal@126.com
Date:
The following bug has been logged on the website:

Bug reference:      7840
Logged by:          digoal
Email address:      digoal@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=3D# begin;
BEGIN
digoal=3D# select * from test where id=3D1 for no key update;
 id =

----
  1
(1 row)
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 =

----+--------+----------+--------+--------+--------+----------+--------+---=
----------+------------+--------+--------+-------
  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=3D# begin;
BEGIN
digoal=3D# select * from test where id=3D1 for key share;
 id =

----
  1
(1 row)

digoal=3D# select * from test where id=3D1 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=3D# begin;
BEGIN
digoal=3D# select * from test where id=3D1 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=3D# select * from test where id=3D1 for share;
 id =

----
  1
(1 row)
but in correct rule, another session cann't get the share lock.
It's a BUG?

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

From
Alvaro Herrera
Date:
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

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

From
Alvaro Herrera
Date:
digoal@126.com wrote:
> The following bug has been logged on the website:
>=20
> Bug reference:      7840
> Logged by:          digoal
> Email address:      digoal@126.com
> 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.

--=20
=C1lvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services