Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pWJ4b-0001ND-Jf for pgsql-hackers@arkaria.postgresql.org; Sun, 26 Feb 2023 15:36:25 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1pWJ4a-0000l8-EN for pgsql-hackers@arkaria.postgresql.org; Sun, 26 Feb 2023 15:36:24 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pWJ4a-0000kz-1l for pgsql-hackers@lists.postgresql.org; Sun, 26 Feb 2023 15:36:24 +0000 Received: from mail-pl1-x643.google.com ([2607:f8b0:4864:20::643]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1pWJ4X-0005Ae-BU for pgsql-hackers@lists.postgresql.org; Sun, 26 Feb 2023 15:36:23 +0000 Received: by mail-pl1-x643.google.com with SMTP id i5so2589322pla.2 for ; Sun, 26 Feb 2023 07:36:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1677425779; h=message-id:mime-version:references:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=BPrM/hvAy0plNtCKE8/Xaa0XaZKQjpxDQWPVV0vumJ4=; b=jDqp0zWIDwckNnXuxrmA2k+l6+Wk2v9l/8GpRZYp+MjV5XSXRf69VrLi8oC0yEDkqz PYAjQOzgxRM6zVUpBjcqGH3ysQaHyOa6BUibRn5jz3NfABtwfj72hq5YO6C+3lbSnjHj 2iy6qLH2ZT2TPbrowWbIFwQE41CKAzipOgFvF5hg0Pk/3W8EeYalZtKto2Nh5+hfQWyx SjWwL5/WtK4ukytUeq2z84RD3drSB5JJrn1NVZZNlMgonmuwUtR8114vHjaAOBBtitrt dQX+PVSczGLc2noOVoURDyOSMpAmYsKSph+WMnwKh5x17vWl4HNhG8hBkCUd/DzeWwCl vZZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1677425779; h=message-id:mime-version:references:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=BPrM/hvAy0plNtCKE8/Xaa0XaZKQjpxDQWPVV0vumJ4=; b=ApztzfTXAUwepD4fiD71BSihLlgxRcKhjIlJwVf8wkJz9eJ0tgvgrvmDoDo+RdvOis ozZNByq5zMmf+yEJdBv+WvySv2f/2C8iwuTJkJeYHQaMvHyXGAyeA495bVGE8Y1DgwjI QxCHbZ1yyVlRkb9MqbAbXq1SG5KTMwdsY3ZoMNl3nyGJpZ/MQ1YGSbSheTZWwLzP27NL Uh/3R2coZ5iiPpY9oHRMLqvubCnHYvE+pVkiQ12hgnvJzsHHgdQYO8gWrGfrXkEY4Idg YjiHGXniQIUSbMyeZjTmsT+GqQXGzbKImpdAIQRm9ptOT+JCE083iBwZ9sXc6NGyT9bf v/bg== X-Gm-Message-State: AO0yUKWiPatqHD7VXvB0Wr0VOUOZib+KTWY/XUZz1UUgHO0RBir4wdFn X0XRvq6SLQLFV2WZl4tvYHg= X-Google-Smtp-Source: AK7set+Okuq3QCqkEdQ3Zuu5hXx7DglOKx86XRv2TCVpsvyyPanYNrffDsgO7NK4HJVThdagFYqrMQ== X-Received: by 2002:a17:902:e84b:b0:19a:7439:3e98 with SMTP id t11-20020a170902e84b00b0019a74393e98mr23416733plg.4.1677425779032; Sun, 26 Feb 2023 07:36:19 -0800 (PST) Received: from LAPTOP-6BJT67H1 ([221.12.59.213]) by smtp.gmail.com with ESMTPSA id b23-20020a170902b61700b0019ac9c4f32esm2768428pls.309.2023.02.26.07.36.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 26 Feb 2023 07:36:18 -0800 (PST) Date: Sun, 26 Feb 2023 23:36:18 +0800 From: "jacktby@gmail.com" To: "Tomas Vondra" Cc: pgsql-hackers Subject: Re: Re: Give me more details of some bits in infomask!! References: <2023022622305600049813@gmail.com>, <3936d2fb-f229-63fd-26e1-130fbe918f51@enterprisedb.com> X-Priority: 3 X-GUID: 35B5B696-08E6-405F-AED9-DA297A44C8C2 X-Has-Attach: no X-Mailer: Foxmail 7.2.25.213[cn] Mime-Version: 1.0 Message-ID: <2023022623361741590024@gmail.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart270588065034_=----" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk This is a multi-part message in MIME format. ------=_001_NextPart270588065034_=---- Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 IA0KRnJvbTogVG9tYXMgVm9uZHJhDQpEYXRlOiAyMDIzLTAyLTI2IDIzOjIzDQpUbzogamFja3Ri eUBnbWFpbC5jb207IHBnc3FsLWhhY2tlcnMNClN1YmplY3Q6IFJlOiBHaXZlIG1lIG1vcmUgZGV0 YWlscyBvZiBzb21lIGJpdHMgaW4gaW5mb21hc2shIQ0KT24gMi8yNi8yMyAxNTozMCwgamFja3Ri eUBnbWFpbC5jb20gd3JvdGU6DQo+IGhlcmUgYXJlIHRoZSBzb3VyY2UgY29kZXMgZnJvbSBzcmMv aW5jbHVkZS9hY2Nlc3MvaHR1cF9kZXRhaWxzLmguDQo+IC8qDQo+ICAqIGluZm9ybWF0aW9uIHN0 b3JlZCBpbiB0X2luZm9tYXNrOg0KPiAgKi8NCj4gI2RlZmluZSBIRUFQX0hBU05VTEwweDAwMDEv KiBoYXMgbnVsbCBhdHRyaWJ1dGUocykgKi8NCj4gI2RlZmluZSBIRUFQX0hBU1ZBUldJRFRIMHgw MDAyLyogaGFzIHZhcmlhYmxlLXdpZHRoIGF0dHJpYnV0ZShzKSAqLw0KPiAjZGVmaW5lIEhFQVBf SEFTRVhURVJOQUwweDAwMDQvKiBoYXMgZXh0ZXJuYWwgc3RvcmVkIGF0dHJpYnV0ZShzKSAqLw0K PiAjZGVmaW5lIEhFQVBfSEFTT0lEX09MRDB4MDAwOC8qIGhhcyBhbiBvYmplY3QtaWQgZmllbGQg Ki8NCj4gI2RlZmluZSBIRUFQX1hNQVhfS0VZU0hSX0xPQ0sweDAwMTAvKiB4bWF4IGlzIGEga2V5 LXNoYXJlZCBsb2NrZXIgKi8NCj4gI2RlZmluZSBIRUFQX0NPTUJPQ0lEMHgwMDIwLyogdF9jaWQg aXMgYSBjb21ibyBDSUQgKi8NCj4gI2RlZmluZSBIRUFQX1hNQVhfRVhDTF9MT0NLMHgwMDQwLyog eG1heCBpcyBleGNsdXNpdmUgbG9ja2VyICovDQo+ICNkZWZpbmUgSEVBUF9YTUFYX0xPQ0tfT05M WTB4MDA4MC8qIHhtYXgsIGlmIHZhbGlkLCBpcyBvbmx5IGEgbG9ja2VyICovDQo+IA0KPiBBbmQg SSBjYW4ndCB1bmRlcnN0YW5kIHRoZXNlIGF0dHJzOg0KIA0KSSBzdWdnZXN0IHlvdSB0cnkgc29t ZXRoaW5nIGxpa2UgJ2dpdCBncmVwIEhFQVBfSEFTRVhURVJOQUwnIHdoaWNoIHNob3dzDQp5b3Ug d2hlcmUgdGhlIGZsYWcgaXMgdXNlZCwgd2hpY2ggc2hvdWxkIHRlbGwgeW91IHdoYXQgaXQgbWVh bnMuIFRoZXNlDQpzaG9ydCBkZXNjcmlwdGlvbnMgZ2VuZXJhbGx5IGFzc3VtZSB5b3Uga25vdyBl bm91Z2ggYWJvdXQgdGhlIGludGVybmFscy4NCiANCj4gMS4gZXh0ZXJuYWwgc3RvcmVkIGF0dHJp YnV0ZShzKSwgd2hhdCBpcyB0aGlzPyAgY2FuIHlvdSBnaXZlIGEgY3JlYXRlDQo+IHN0YXRlbWVu dCB0byBzaG93IG1lPw0KIA0KZXh0ZXJuYWwgPSB2YWx1ZSBzdG9yZWQgaW4gYSBUT0FTVCB0YWJs ZQ0KIA0KPiAyLiB4bWF4IGlzIGEga2V5LXNoYXJlZCBsb2NrZXIvZXhjbHVzaXZlIGxvY2tlci9v bmx5IGEgbG9ja2VyLCBzbyBob3cNCj4geW91IHVzZSB0aGlzPyBjYW4geW91IGdpdmUgbWUgYSAg c2NlbmFyaW8/DQo+IGxldCBtZSB0cnkgdG8gZXhwbGFpbiBpdDoNCj4gIGlmIHRoZXJlIGlzIGEg dHhuIGlzIHRyeWluZyB0byByZWFkIHRoaXMgaGVhcHR1cGxlLA0KPiB0aGUgSEVBUF9YTUFYX0tF WVNIUl9MT0NLIGJpdCB3aWxsIGJlIHNldCB0byAxLg0KPiAgaWYgdGhlcmUgaXMgYSB0eG4gaXMg dHJ5aW5nIHRvIGRlbGV0ZS91cGRhdGUgdGhpcyBoZWFwdHVwbGUsDQo+IHRoZSBIRUFQX1hNQVhf RVhDTF9MT0NLIGJpdCB3aWxsIGJlIHNldCB0byAxLg0KPiAgYnV0IGZvciBIRUFQX1hNQVhfTE9D S19PTkxZLCBJIGNhbid0IHVuZGVyc3RhbmQuDQo+IEFuZCBhbm90aGVyIHRob3VnaHQgaXMgdGhh dCB0aGVzZSB0aHJlZSBiaXQgY2FuIGhhdmUgb25seSBvbmUgdG8gYmUgc2V0DQo+IDEgYXQgbW9z dC4NCiANCkkgYmVsaWV2ZSBIRUFQX1hNQVhfTE9DS19PTkxZIG1lYW5zIHRoZSB4bWF4IHRyYW5z YWN0aW9uIG9ubHkgbG9ja2VkIHRoZQ0KdHVwbGUsIHdpdGhvdXQgZGVsZXRpbmcvdXBkYXRpbmcg aXQuDQogDQo+IDMuIHRfY2lkIGlzIGEgY29tYm8gQ0lEPyB3aGF0J3MgYSBDSUQ/IGdpdmUgbWUg YW4gZXhhbXBsZSBwbGVhc2UuDQogDQpDSUQgbWVhbnMgImNvbW1hbmQgSUQiIGkuZS4gc2VxdWVu dGlhbCBJRCBhc3NpZ25lZCB0byBjb21tYW5kcyBpbiBhDQpzaW5nbGUgc2Vzc2lvbiAoZm9yIHZp c2liaWxpdHkgY2hlY2tzLCBzbyB0aGF0IGEgcXVlcnkgZG9lc24ndCBzZWUgZGF0YQ0KZGVsZXRl ZCBieSBlYXJsaWVyIGNvbW1hbmRzIGluIHRoZSBzYW1lIHNlc3Npb24pLiBTZWUNCnNyYy9iYWNr ZW5kL3V0aWxzL3RpbWUvY29tYm9jaWQuYyBmb3IgYmFzaWMgZXhwbGFuYXRpb24gb2Ygd2hhdCAi Y29tYm8NCkNJRCIgaXMuDQogDQogDQpyZWdhcmRzDQogDQotLSANClRvbWFzIFZvbmRyYQ0KRW50 ZXJwcmlzZURCOiBodHRwOi8vd3d3LmVudGVycHJpc2VkYi5jb20NClRoZSBFbnRlcnByaXNlIFBv c3RncmVTUUwgQ29tcGFueQ0KDQoNCj4gSSBiZWxpZXZlIEhFQVBfWE1BWF9MT0NLX09OTFkgbWVh bnMgdGhlIHhtYXggdHJhbnNhY3Rpb24gb25seSBsb2NrZWQgdGhlDQo+IHR1cGxlLCB3aXRob3V0 IGRlbGV0aW5nL3VwZGF0aW5nIGl0Lg0KaWYgc28sIHlvdSBtZWFuIHdoZW4gSSByZWFkIHRoaXMg dHVwbGUsIHRoaXMgYml0IHdpbGwgYmUgc2V0IDEsIGJ1dCBJIHRoaW5rIHRoaXMgaXMgZHVwbGlj YXQgd2l0aCBIRUFQX1hNQVhfS0VZU0hSX0xPQ0suDQoNCj4gQ0lEIG1lYW5zICJjb21tYW5kIElE IiBpLmUuIHNlcXVlbnRpYWwgSUQgYXNzaWduZWQgdG8gY29tbWFuZHMgaW4gYQ0KPiBzaW5nbGUg c2Vzc2lvbiAoZm9yIHZpc2liaWxpdHkgY2hlY2tzLCBzbyB0aGF0IGEgcXVlcnkgZG9lc24ndCBz ZWUgZGF0YQ0KPiBkZWxldGVkIGJ5IGVhcmxpZXIgY29tbWFuZHMgaW4gdGhlIHNhbWUgc2Vzc2lv bikuIFNlZQ0KPiBzcmMvYmFja2VuZC91dGlscy90aW1lL2NvbWJvY2lkLmMgZm9yIGJhc2ljIGV4 cGxhbmF0aW9uIG9mIHdoYXQgImNvbWJvDQo+IENJRCIgaXMuDQpJIHRoaW5rIGlmIGNpZCBpcyB1 c2VkIGZvciAgdmlzaWJpbGl0eSBjaGVja3MgaW4gb25lIHNlc3Npb24sIHRoYXQncyBtZWFpbmds ZXNzLCBiZWFjYXVzZSB3ZSBjYW4gdXNlIHRoZSB0X3htaW4gYW5kIHRfeG1heCB0byANCmdldCB0 aGlzIGdvYWwuIElzIHRpcyANCg== ------=_001_NextPart270588065034_=---- Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = =0A
 
Date: 2023-02-26 23:2= 3
Subject: Re: Give me more details of som= e bits in infomask!!
On 2/26/23 15:30, jacktby@= gmail.com wrote:
=0A
> here are the source codes from src/incl= ude/access/htup_details.h.
=0A
> /*
=0A
>  * = information stored in t_infomask:
=0A
>  */
=0A
= > #define HEAP_HASNULL0x0001/* has null attribute(s) */
=0A
&g= t; #define HEAP_HASVARWIDTH0x0002/* has variable-width attribute(s) */=0A
> #define HEAP_HASEXTERNAL0x0004/* has external stored attrib= ute(s) */
=0A
> #define HEAP_HASOID_OLD0x0008/* has an object-= id field */
=0A
> #define HEAP_XMAX_KEYSHR_LOCK0x0010/* xmax i= s a key-shared locker */
=0A
> #define HEAP_COMBOCID0x0020/* t= _cid is a combo CID */
=0A
> #define HEAP_XMAX_EXCL_LOCK0x0040= /* xmax is exclusive locker */
=0A
> #define HEAP_XMAX_LOCK_ON= LY0x0080/* xmax, if valid, is only a locker */
=0A
>
=0A=
> And I can't understand these attrs:
=0A
 
=0A=
I suggest you try something like 'git grep HEAP_HASEXTERNAL' which sh= ows
=0A
you where the flag is used, which should tell you what it= means. These
=0A
short descriptions generally assume you know en= ough about the internals.
=0A
 
=0A
> 1. ex= ternal stored attribute(s), what is this?  can you give a create=0A
> statement to show me?
=0A
 
=0A
exter= nal =3D value stored in a TOAST table
=0A
 
=0A
>= ; 2. xmax is a key-shared locker/exclusive locker/only a locker, so h= ow
=0A
> you use this? can you give me a  scenario?<= /div>=0A
> let me try to explain it:
=0A
>  if the= re is a txn is trying to read this heaptuple,
=0A
> the H= EAP_XMAX_KEYSHR_LOCK bit will be set to 1.
=0A
>  if = ;there is a txn is trying to delete/update this heaptuple,
=0A
&g= t; the HEAP_XMAX_EXCL_LOCK bit will be set to 1.
=0A
&g= t;  but for HEAP_XMAX_LOCK_ONLY, I can't understand.
=0A> And another thought is that these three bit can have only one to be= set
=0A
> 1 at most.
=0A
 
=0A
I belie= ve HEAP_XMAX_LOCK_ONLY means the xmax transaction only locked the
=0A=
tuple, without deleting/updating it.
=0A
 
=0A> 3. t_cid is a combo CID? what's a CID? give me an example pleas= e.
=0A
 
=0A
CID means "command ID" i.e. sequential= ID assigned to commands in a
=0A
single session (for visibility = checks, so that a query doesn't see data
=0A
deleted by earlier c= ommands in the same session). See
=0A
src/backend/utils/time/comb= ocid.c for basic explanation of what "combo
=0A
CID" is.
=0A=
 
=0A
 
=0A
regards
=0A
 =0A
--
=0A
Tomas Vondra
=0A
EnterpriseDB: http:= //www.enterprisedb.com
=0A
The Enterprise PostgreSQL Company


I believe HEAP_XMAX_LOCK_ONLY means the xmax transactio= n only locked the
> tuple, without deleting/updating i= t.
if so, you mean when I read this tuple, this bit will be set = 1, but I think this is duplicat with HEAP_XMAX_KEYSHR_LOCK.

> CID means "com= mand ID" i.e. sequential ID assigned to commands in a
> singl= e session (for visibility checks, so that a query doesn't see data
> deleted by earlier commands in the same session). See
&g= t; src/backend/utils/time/combocid.c for basic explanation of what "combo<= /div>
> CID" is.
I think if cid is used for  visibility checks in one session, that's me= aingless, beacause we can use the t_xmin and t_xmax to 
<= div>get this goal. Is tis&n= bsp;
=0A
=0A ------=_001_NextPart270588065034_=------