Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1revV4-00EHmx-GX for pgsql-hackers@arkaria.postgresql.org; Tue, 27 Feb 2024 11:19:56 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1revV2-002IeR-Th for pgsql-hackers@arkaria.postgresql.org; Tue, 27 Feb 2024 11:19:53 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1revV2-002IeJ-5f for pgsql-hackers@lists.postgresql.org; Tue, 27 Feb 2024 11:19:53 +0000 Received: from mail.postgrespro.ru ([93.174.131.139]) by makus.postgresql.org with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1revUu-001TUU-Oa for pgsql-hackers@lists.postgresql.org; Tue, 27 Feb 2024 11:19:51 +0000 Received: from sogo.postgrespro.ru (unknown [192.168.2.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail.postgrespro.ru (Postfix/587) with ESMTPS id 74E04E20E83; Tue, 27 Feb 2024 14:19:41 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=postgrespro.ru; s=mx2023; t=1709032781; bh=I5DMGmicx8a0ecuPFWBTN1XbeAordXe5Z04vPRwgZxI=; h=From:In-Reply-To:References:Date:Cc:To:Message-ID:Subject: User-Agent:From; b=gXvlwS38hCrZzU7SPOsOMBAhEvSny457uhh5eJ5u+7z/j38L2pJWl/Ddu5++BjgSB C1X/E66rIH/sjEX8vGUYgDm1KRuNGKzA6XzUkBBrcgf1Rfn+mHYyueUG1WmSH/BCv4 ZSvyQF2tMTw88FlAI6TwZFc6ew8Xt1l1tHgzGaZsREQxEsxhrMkpH9hwA3uRbxdX3l fOpqce/WoszdxJN0GATyze7TpKdLHq1p3x49SuNz6gqeQ88hcK9adv4342TiWqeaXC RDVtO+88vHGqYY4gOBen2ZoXWxuJr3AE5faeWgOKb4duvjjrtvFUefVxwh2mCPIkon oR7V1x/SPshQA== From: =?utf-8?q?=D0=94=D0=B0=D0=B2=D1=8B=D0=B4=D0=BE=D0=B2_=D0=92=D0=B8=D1=82=D0=B0=D0=BB=D0=B8=D0=B9?= Content-Type: multipart/mixed; boundary="----=_=-_OpenGroupware_org_NGMime-763062-1709032781.343304-5------" In-Reply-To: X-Forward: 93.174.131.141 References: <8fab8-65d74c80-1-2f28e880@39088166> <99df2-65d8d200-1-63c26880@172687752> Date: Tue, 27 Feb 2024 14:19:41 +0300 Cc: pgsql-hackers@lists.postgresql.org To: "Amit Kapila" MIME-Version: 1.0 Message-ID: Subject: =?utf-8?q?Re=3A?= Slow catchup of 2PC (twophase) transactions on replica in LR User-Agent: SOGoMail 5.9.1 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk ------=_=-_OpenGroupware_org_NGMime-763062-1709032781.343304-5------ Content-Type: multipart/alternative; boundary="----=_=-_OpenGroupware_org_NGMime-763062-1709032781.343179-4------" ------=_=-_OpenGroupware_org_NGMime-763062-1709032781.343179-4------ Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Length: 1863 Hi Amit, Thank you for your interest in the discussion! On Monday, February 26, 2024 16:24 MSK, Amit Kapila wrote: =C2=A0 I think the reason is probably that when the WAL record for prepared is= already flushed then what will be the idea of async commit here?I thin= k, the idea of async commit should be applied for both transactions: PR= EPARE and COMMIT PREPARED, which are actually two separate local transa= ctions.=C2=A0For both these transactions=C2=A0we may call XLogSetAsyncX= actLSN on commit instead of XLogFlush when async commit is enabled. Whe= n I use async commit, I mean to apply async commit to local transaction= s, not to a twophase (prepared) transaction itself. =C2=A0 At commit prepared, it seems we read prepare's WAL record, right? If so= , it is not clear to me do you see a problem with a flush of commit=5Fp= repared or reading WAL for prepared or both of these.The problem with r= eading WAL is due to async commit of PREPARE TRANSACTION which saves 2P= C in the WAL. At the moment of COMMIT PREPARED the WAL with PREPARE TRA= NSACTION 2PC state may not be XLogFlush-ed yet. So, PREPARE TRANSACTION= should wait until its 2PC state is flushed. I did some experiments with saving 2PC state in the local memory of log= ical replication worker and, I think, it worked and demonstrated much b= etter performance. Logical replication worker utilized up to 100% CPU. = I'm just concerned about possible problems with async commit for twopha= se transactions. To be more specific, I've attached a patch to support async commit for = twophase. It is not the final patch but it is presented only for discus= sion purposes. There were some attempts to save 2PC in memory in past b= ut it was rejected. Now, there might be the second round to discuss it. With best regards, Vitaly =C2=A0 ------=_=-_OpenGroupware_org_NGMime-763062-1709032781.343179-4------ Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Length: 2036 Hi Amit,

Thank you for your interest in the discussion= !

On Monday, February 26, 2024 16:24 MSK, Amit Kapila <am= it.kapila16@gmail.com> wrote:
 

I think the = reason is probably that when the WAL record for prepared is already flu= shed then what will be the idea of async commit here?

I= think, the idea of async commit should be applied for both transaction= s: PREPARE and COMMIT PREPARED, which are actually two separate local t= ransactions. For both these transactions we may call XLogSetA= syncXactLSN on commit instead of XLogFlush when async commit is enabled= . When I use async commit, I mean to apply async commit to local transa= ctions, not to a twophase (prepared) transaction itself.
 

At commit prepared, it seems we read prepare's WAL record, = right? If so, it is not clear to me do you see a problem with a flush o= f commit=5Fprepared or reading WAL for prepared or both of these.

The problem with reading WAL is due to async commit of PREPA= RE TRANSACTION which saves 2PC in the WAL. At the moment of COMMIT PREP= ARED the WAL with PREPARE TRANSACTION 2PC state may not be XLogFlush-ed= yet. So, PREPARE TRANSACTION should wait until its 2PC state is flushe= d.

I did some experiments with saving 2PC state in the local= memory of logical replication worker and, I think, it worked and demon= strated much better performance. Logical replication worker utilized up= to 100% CPU. I'm just concerned about possible problems with async com= mit for twophase transactions.

To be more specific, I've att= ached a patch to support async commit for twophase. It is not the final= patch but it is presented only for discussion purposes. There were som= e attempts to save 2PC in memory in past but it was rejected. Now, ther= e might be the second round to discuss it.

With best regards= ,
Vitaly

  ------=_=-_OpenGroupware_org_NGMime-763062-1709032781.343179-4-------- ------=_=-_OpenGroupware_org_NGMime-763062-1709032781.343304-5------ Content-Type: text/x-patch Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="0001-Add-asynchronous-commit-support-for-2PC.patch" Content-Length: 8204 RnJvbSA1NDlmODA5ZmExMjJjYTA4NDJlYzRiZmM3NzVhZmQwOGZlZWUwZDgwIE1vbiBTZXAg MTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBWaXRhbHkgRGF2eWRvdiA8di5kYXZ5ZG92QHBvc3Rn cmVzcHJvLnJ1PgpEYXRlOiBUdWUsIDI3IEZlYiAyMDI0IDE0OjAyOjIzICswMzAwClN1Ympl Y3Q6IFtQQVRDSF0gQWRkIGFzeW5jaHJvbm91cyBjb21taXQgc3VwcG9ydCBmb3IgMlBDCgot LS0KIHNyYy9iYWNrZW5kL2FjY2Vzcy90cmFuc2FtL3R3b3BoYXNlLmMgfCAxMTEgKysrKysr KysrKysrKysrKysrKysrKysrKy0KIDEgZmlsZSBjaGFuZ2VkLCAxMDggaW5zZXJ0aW9ucygr KSwgMyBkZWxldGlvbnMoLSkKCmRpZmYgLS1naXQgYS9zcmMvYmFja2VuZC9hY2Nlc3MvdHJh bnNhbS90d29waGFzZS5jIGIvc3JjL2JhY2tlbmQvYWNjZXNzL3RyYW5zYW0vdHdvcGhhc2Uu YwppbmRleCBjNmFmOGNmZDdlLi41MmYwODUzZGI4IDEwMDY0NAotLS0gYS9zcmMvYmFja2Vu ZC9hY2Nlc3MvdHJhbnNhbS90d29waGFzZS5jCisrKyBiL3NyYy9iYWNrZW5kL2FjY2Vzcy90 cmFuc2FtL3R3b3BoYXNlLmMKQEAgLTEwOSw2ICsxMDksOCBAQAogI2luY2x1ZGUgInV0aWxz L21lbXV0aWxzLmgiCiAjaW5jbHVkZSAidXRpbHMvdGltZXN0YW1wLmgiCiAKKyNkZWZpbmUg UE9TVEdSRVNRTF9UV09QSEFTRV9TVVBQT1JUX0FTWU5DX0NPTU1JVAorCiAvKgogICogRGly ZWN0b3J5IHdoZXJlIFR3by1waGFzZSBjb21taXQgZmlsZXMgcmVzaWRlIHdpdGhpbiBQR0RB VEEKICAqLwpAQCAtMTYzLDYgKzE2NSw5IEBAIHR5cGVkZWYgc3RydWN0IEdsb2JhbFRyYW5z YWN0aW9uRGF0YQogCSAqLwogCVhMb2dSZWNQdHIJcHJlcGFyZV9zdGFydF9sc247CS8qIFhM T0cgb2Zmc2V0IG9mIHByZXBhcmUgcmVjb3JkIHN0YXJ0ICovCiAJWExvZ1JlY1B0cglwcmVw YXJlX2VuZF9sc247CS8qIFhMT0cgb2Zmc2V0IG9mIHByZXBhcmUgcmVjb3JkIGVuZCAqLwor CXZvaWQqICAgICAgIHByZXBhcmVfMnBjX21lbV9kYXRhOworCXNpemVfdCAgICAgIHByZXBh cmVfMnBjX21lbV9sZW47CisJcGlkX3QgICAgICAgcHJlcGFyZV8ycGNfcHJvYzsKIAlUcmFu c2FjdGlvbklkIHhpZDsJCQkvKiBUaGUgR1hBQ1QgaWQgKi8KIAogCU9pZAkJCW93bmVyOwkJ CS8qIElEIG9mIHVzZXIgdGhhdCBleGVjdXRlZCB0aGUgeGFjdCAqLwpAQCAtNDI3LDYgKzQz Miw5IEBAIE1hcmtBc1ByZXBhcmluZyhUcmFuc2FjdGlvbklkIHhpZCwgY29uc3QgY2hhciAq Z2lkLAogCiAJTWFya0FzUHJlcGFyaW5nR3V0cyhneGFjdCwgeGlkLCBnaWQsIHByZXBhcmVk X2F0LCBvd25lciwgZGF0YWJhc2VpZCk7CiAKKwlBc3NlcnQoZ3hhY3QtPnByZXBhcmVfMnBj X21lbV9kYXRhID09IE5VTEwpOworCUFzc2VydChneGFjdC0+cHJlcGFyZV8ycGNfcHJvYyA9 PSAwKTsKKwogCWd4YWN0LT5vbmRpc2sgPSBmYWxzZTsKIAogCS8qIEFuZCBpbnNlcnQgaXQg aW50byB0aGUgYWN0aXZlIGFycmF5ICovCkBAIC0xMTI5LDYgKzExMzcsOCBAQCBTdGFydFBy ZXBhcmUoR2xvYmFsVHJhbnNhY3Rpb24gZ3hhY3QpCiAJfQogfQogCitleHRlcm4gYm9vbCBJ c0xvZ2ljYWxXb3JrZXIodm9pZCk7CisKIC8qCiAgKiBGaW5pc2ggcHJlcGFyaW5nIHN0YXRl IGRhdGEgYW5kIHdyaXRpbmcgaXQgdG8gV0FMLgogICovCkBAIC0xMTY3LDYgKzExNzcsMzcg QEAgRW5kUHJlcGFyZShHbG9iYWxUcmFuc2FjdGlvbiBneGFjdCkKIAkJCQkoZXJyY29kZShF UlJDT0RFX1BST0dSQU1fTElNSVRfRVhDRUVERUQpLAogCQkJCSBlcnJtc2coInR3by1waGFz ZSBzdGF0ZSBmaWxlIG1heGltdW0gbGVuZ3RoIGV4Y2VlZGVkIikpKTsKIAorCUFzc2VydChn eGFjdC0+cHJlcGFyZV8ycGNfbWVtX2RhdGEgPT0gTlVMTCk7CisJQXNzZXJ0KGd4YWN0LT5w cmVwYXJlXzJwY19wcm9jID09IDApOworCisJaWYgKElzTG9naWNhbFdvcmtlcigpKQorCXsK KwkJc2l6ZV90CQkJbGVuID0gMDsKKwkJc2l6ZV90CQkJb2Zmc2V0ID0gMDsKKworCQlmb3Ig KHJlY29yZCA9IHJlY29yZHMuaGVhZDsgcmVjb3JkICE9IE5VTEw7IHJlY29yZCA9IHJlY29y ZC0+bmV4dCkKKwkJCWxlbiArPSByZWNvcmQtPmxlbjsKKworCQlpZiAobGVuID4gMCkKKwkJ eworCQkJTWVtb3J5Q29udGV4dAlvbGRtZW1jdHg7CisKKwkJCW9sZG1lbWN0eCA9IE1lbW9y eUNvbnRleHRTd2l0Y2hUbyhUb3BNZW1vcnlDb250ZXh0KTsKKworCQkJZ3hhY3QtPnByZXBh cmVfMnBjX21lbV9kYXRhID0gcGFsbG9jKGxlbik7CisJCQlneGFjdC0+cHJlcGFyZV8ycGNf bWVtX2xlbiA9IGxlbjsKKwkJCWd4YWN0LT5wcmVwYXJlXzJwY19wcm9jID0gZ2V0cGlkKCk7 CisKKwkJCWZvciAocmVjb3JkID0gcmVjb3Jkcy5oZWFkOyByZWNvcmQgIT0gTlVMTDsgcmVj b3JkID0gcmVjb3JkLT5uZXh0KQorCQkJeworCQkJCW1lbWNweSgoY2hhciAqKWd4YWN0LT5w cmVwYXJlXzJwY19tZW1fZGF0YSArIG9mZnNldCwgcmVjb3JkLT5kYXRhLCByZWNvcmQtPmxl bik7CisJCQkJb2Zmc2V0ICs9IHJlY29yZC0+bGVuOworCQkJfQorCisJCQlNZW1vcnlDb250 ZXh0U3dpdGNoVG8ob2xkbWVtY3R4KTsKKwkJfQorCX0KKwogCS8qCiAJICogTm93IHdyaXRp bmcgMlBDIHN0YXRlIGRhdGEgdG8gV0FMLiBXZSBsZXQgdGhlIFdBTCdzIENSQyBwcm90ZWN0 aW9uCiAJICogY292ZXIgdXMsIHNvIG5vIG5lZWQgdG8gY2FsY3VsYXRlIGEgc2VwYXJhdGUg Q1JDLgpAQCAtMTIwMiw4ICsxMjQzLDI0IEBAIEVuZFByZXBhcmUoR2xvYmFsVHJhbnNhY3Rp b24gZ3hhY3QpCiAJCQkJCQkJCSAgIGd4YWN0LT5wcmVwYXJlX2VuZF9sc24pOwogCX0KIAor I2lmICFkZWZpbmVkKFBPU1RHUkVTUUxfVFdPUEhBU0VfU1VQUE9SVF9BU1lOQ19DT01NSVQp CisKIAlYTG9nRmx1c2goZ3hhY3QtPnByZXBhcmVfZW5kX2xzbik7CiAKKyNlbHNlCisKKwlp ZiAoc3luY2hyb25vdXNfY29tbWl0ID4gU1lOQ0hST05PVVNfQ09NTUlUX09GRikKKwl7CisJ CS8qIEZsdXNoIFhMT0cgdG8gZGlzayAqLworCQlYTG9nRmx1c2goZ3hhY3QtPnByZXBhcmVf ZW5kX2xzbik7CisJfQorCWVsc2UKKwl7CisJCVhMb2dTZXRBc3luY1hhY3RMU04oZ3hhY3Qt PnByZXBhcmVfZW5kX2xzbik7CisJfQorCisjZW5kaWYKKwogCS8qIElmIHdlIGNyYXNoIG5v dywgd2UgaGF2ZSBwcmVwYXJlZDogV0FMIHJlcGxheSB3aWxsIGZpeCB0aGluZ3MgKi8KIAog CS8qIFN0b3JlIHJlY29yZCdzIHN0YXJ0IGxvY2F0aW9uIHRvIHJlYWQgdGhhdCBsYXRlciBv biBDb21taXQgKi8KQEAgLTE0OTUsNiArMTU1Miw3IEBAIEZpbmlzaFByZXBhcmVkVHJhbnNh Y3Rpb24oY29uc3QgY2hhciAqZ2lkLCBib29sIGlzQ29tbWl0KQogCXhsX3hhY3Rfc3RhdHNf aXRlbSAqY29tbWl0c3RhdHM7CiAJeGxfeGFjdF9zdGF0c19pdGVtICphYm9ydHN0YXRzOwog CVNoYXJlZEludmFsaWRhdGlvbk1lc3NhZ2UgKmludmFsbXNnczsKKwlib29sCQlpc19sb2Nh bF8ycGNfYnVmID0gZmFsc2U7CiAKIAkvKgogCSAqIFZhbGlkYXRlIHRoZSBHSUQsIGFuZCBs b2NrIHRoZSBHWEFDVCB0byBlbnN1cmUgdGhhdCB0d28gYmFja2VuZHMgZG8gbm90CkBAIC0x NTA5LDEyICsxNTY3LDE5IEBAIEZpbmlzaFByZXBhcmVkVHJhbnNhY3Rpb24oY29uc3QgY2hh ciAqZ2lkLCBib29sIGlzQ29tbWl0KQogCSAqIGluIFdBTCBmaWxlcyBpZiB0aGUgTFNOIGlz IGFmdGVyIHRoZSBsYXN0IGNoZWNrcG9pbnQgcmVjb3JkLCBvciBtb3ZlZAogCSAqIHRvIGRp c2sgaWYgZm9yIHNvbWUgcmVhc29uIHRoZXkgaGF2ZSBsaXZlZCBmb3IgYSBsb25nIHRpbWUu CiAJICovCi0JaWYgKGd4YWN0LT5vbmRpc2spCisJaWYgKGd4YWN0LT5wcmVwYXJlXzJwY19t ZW1fZGF0YSAhPSBOVUxMICYmIGd4YWN0LT5wcmVwYXJlXzJwY19wcm9jID09IGdldHBpZCgp KQorCXsKKwkJQXNzZXJ0KElzTG9naWNhbFdvcmtlcigpKTsKKwkJQXNzZXJ0KGd4YWN0LT5w cmVwYXJlXzJwY19wcm9jID09IGdldHBpZCgpKTsKKwkJYnVmID0gZ3hhY3QtPnByZXBhcmVf MnBjX21lbV9kYXRhOworCQkvKiBlcmVwb3J0KExPRywgZXJybXNnKCIlczolZCIsIF9fRlVO Q1RJT05fXywgX19MSU5FX18pKTsgKi8KKwkJaXNfbG9jYWxfMnBjX2J1ZiA9IHRydWU7CisJ fQorCWVsc2UgaWYgKGd4YWN0LT5vbmRpc2spCiAJCWJ1ZiA9IFJlYWRUd29QaGFzZUZpbGUo eGlkLCBmYWxzZSk7CiAJZWxzZQogCQlYbG9nUmVhZFR3b1BoYXNlRGF0YShneGFjdC0+cHJl cGFyZV9zdGFydF9sc24sICZidWYsIE5VTEwpOwogCi0KIAkvKgogCSAqIERpc2Fzc2VtYmxl IHRoZSBoZWFkZXIgYXJlYQogCSAqLwpAQCAtMTYzOCw2ICsxNzAzLDE5IEBAIEZpbmlzaFBy ZXBhcmVkVHJhbnNhY3Rpb24oY29uc3QgY2hhciAqZ2lkLCBib29sIGlzQ29tbWl0KQogCS8q IENsZWFyIHNoYXJlZCBtZW1vcnkgc3RhdGUgKi8KIAlSZW1vdmVHWGFjdChneGFjdCk7CiAK KwlpZiAoZ3hhY3QtPnByZXBhcmVfMnBjX21lbV9kYXRhICE9IE5VTEwpCisJeworCQlNZW1v cnlDb250ZXh0CQltZW1jdHg7CisJCS8vQXNzZXJ0KGd4YWN0LT5wcmVwYXJlXzJwY19wcm9j ID09IGdldHBpZCgpKTsKKwkJbWVtY3R4ID0gTWVtb3J5Q29udGV4dFN3aXRjaFRvKFRvcE1l bW9yeUNvbnRleHQpOworCQlpZiAoZ3hhY3QtPnByZXBhcmVfMnBjX3Byb2MgPT0gZ2V0cGlk KCkpCisJCQlwZnJlZShneGFjdC0+cHJlcGFyZV8ycGNfbWVtX2RhdGEpOworCQlneGFjdC0+ cHJlcGFyZV8ycGNfbWVtX2RhdGEgPSBOVUxMOworCQlneGFjdC0+cHJlcGFyZV8ycGNfbWVt X2xlbiA9IDA7CisJCWd4YWN0LT5wcmVwYXJlXzJwY19wcm9jID0gMDsKKwkJTWVtb3J5Q29u dGV4dFN3aXRjaFRvKG1lbWN0eCk7CisJfQorCiAJLyoKIAkgKiBSZWxlYXNlIHRoZSBsb2Nr IGFzIGFsbCBjYWxsYmFja3MgYXJlIGNhbGxlZCBhbmQgc2hhcmVkIG1lbW9yeSBjbGVhbnVw CiAJICogaXMgZG9uZS4KQEAgLTE2NTcsNyArMTczNSw4IEBAIEZpbmlzaFByZXBhcmVkVHJh bnNhY3Rpb24oY29uc3QgY2hhciAqZ2lkLCBib29sIGlzQ29tbWl0KQogCiAJUkVTVU1FX0lO VEVSUlVQVFMoKTsKIAotCXBmcmVlKGJ1Zik7CisJaWYgKCFpc19sb2NhbF8ycGNfYnVmKQor CQlwZnJlZShidWYpOwogfQogCiAvKgpAQCAtMjM0OSwxMiArMjQyOCwzOCBAQCBSZWNvcmRU cmFuc2FjdGlvbkNvbW1pdFByZXBhcmVkKFRyYW5zYWN0aW9uSWQgeGlkLAogCSAqIGEgY29u dHJhZGljdGlvbikKIAkgKi8KIAorI2lmICFkZWZpbmVkKFBPU1RHUkVTUUxfVFdPUEhBU0Vf U1VQUE9SVF9BU1lOQ19DT01NSVQpCisKIAkvKiBGbHVzaCBYTE9HIHRvIGRpc2sgKi8KIAlY TG9nRmx1c2gocmVjcHRyKTsKIAogCS8qIE1hcmsgdGhlIHRyYW5zYWN0aW9uIGNvbW1pdHRl ZCBpbiBwZ194YWN0ICovCiAJVHJhbnNhY3Rpb25JZENvbW1pdFRyZWUoeGlkLCBuY2hpbGRy ZW4sIGNoaWxkcmVuKTsKIAorI2Vsc2UKKworCWlmIChzeW5jaHJvbm91c19jb21taXQgPiBT WU5DSFJPTk9VU19DT01NSVRfT0ZGKQorCXsKKwkJLyogRmx1c2ggWExPRyB0byBkaXNrICov CisJCVhMb2dGbHVzaChyZWNwdHIpOworCisJCS8qIE1hcmsgdGhlIHRyYW5zYWN0aW9uIGNv bW1pdHRlZCBpbiBwZ194YWN0ICovCisJCVRyYW5zYWN0aW9uSWRDb21taXRUcmVlKHhpZCwg bmNoaWxkcmVuLCBjaGlsZHJlbik7CisJfQorCWVsc2UKKwl7CisJCVhMb2dTZXRBc3luY1hh Y3RMU04ocmVjcHRyKTsKKworCQkvKgorCQkgKiBXZSBtdXN0IG5vdCBpbW1lZGlhdGVseSB1 cGRhdGUgdGhlIENMT0csIHNpbmNlIHdlIGRpZG4ndCBmbHVzaCB0aGUKKwkJICogWExPRy4g SW5zdGVhZCwgd2Ugc3RvcmUgdGhlIExTTiB1cCB0byB3aGljaCB0aGUgWExPRyBtdXN0IGJl CisJCSAqIGZsdXNoZWQgYmVmb3JlIHRoZSBDTE9HIG1heSBiZSB1cGRhdGVkLgorCQkgKi8K KwkJVHJhbnNhY3Rpb25JZEFzeW5jQ29tbWl0VHJlZSh4aWQsIG5jaGlsZHJlbiwgY2hpbGRy ZW4sIHJlY3B0cik7CisJfQorCisjZW5kaWYKKwogCS8qIENoZWNrcG9pbnQgY2FuIHByb2Nl ZWQgbm93ICovCiAJTXlQcm9jLT5kZWxheUNoa3B0RmxhZ3MgJj0gfkRFTEFZX0NIS1BUX1NU QVJUOwogCi0tIAoyLjM0LjEKCg== ------=_=-_OpenGroupware_org_NGMime-763062-1709032781.343304-5--------