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 1rowxF-004Gyi-L9 for pgsql-hackers@arkaria.postgresql.org; Tue, 26 Mar 2024 02:54:26 +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 1rowxC-00AALM-6L for pgsql-hackers@arkaria.postgresql.org; Tue, 26 Mar 2024 02:54:22 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rowxB-00AAKd-3H for pgsql-hackers@lists.postgresql.org; Tue, 26 Mar 2024 02:54:22 +0000 Received: from wfhigh3-smtp.messagingengine.com ([64.147.123.154]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rowx6-006VkY-8J for pgsql-hackers@lists.postgresql.org; Tue, 26 Mar 2024 02:54:20 +0000 Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailfhigh.west.internal (Postfix) with ESMTP id 4D4A31800103; Mon, 25 Mar 2024 22:54:11 -0400 (EDT) Received: from imap49 ([10.202.2.99]) by compute2.internal (MEProxy); Mon, 25 Mar 2024 22:54:12 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eulerto.com; h= cc:cc:content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:subject :subject:to:to; s=fm3; t=1711421650; x=1711508050; bh=ERLSBBAyrq rNYNkXjYIrTOBEFXXr9rGu1DtCa7vHSJQ=; b=k6wDwWGiw2LfodSZZd6pbDwKqu ISne2TpRzI2s4EcQLlZ3gAN0Dl98gn8TUz5RL4Z1IYzQO2FnlFn7QsqaDzSNf1Z3 peIgBupdLxicKrMjHP2yuwZ/mmvkBXp6nDdgigeqrwOlyc69nrXgxf8Ry9dzRxjB gv9YTykdiuCZE6jXCXuXT40tcJ28gWG/k+b6OjVIfaAEMl8yVqSoUJOh6vtUwqMr rrDult0wCV7y9nr4N2/XN+HUai2/7P5tYR6+JEMa+r6aAdHKaJUzOY9y9xN2ddLj 1x8kapTF4YjAi8fn9QrEHNJUuXcI4DmE5OY6adY4aiuT3+LNG0miHxAiILjg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; t=1711421650; x=1711508050; bh=ERLSBBAyrqrNYNkXjYIrTOBEFXXr 9rGu1DtCa7vHSJQ=; b=wstfWg1aHkai/ulQN7fSjFQPG4xF6lA0rlVGzJSifPtO LoUYV3Sv3b/c8wzQmPs3Vn1o6c3JgenZ9CkBr2y3SD5o0kEps3XHLQ44svjEHPN3 V1yWbQMooRTHCyV/jmYi2N+ek2hCktCqyGlbLjwwsDvXSpsKvJEv6jM+HTIApXUs 2Na8D7GJsXxtuGAvvBMxxExgkUg3OyP0kbadQMm7624Tj1Ssv8F5UGUh3euHN/Ks QKjkyau4NkZWDlndS8VTk5PQBsweZXD2y2ORZHDWV7qJV09S7xsSCcRr93/d9H2Z 5VtDQkCKatBf+BTk++LMrZv2f0nihtl0m7JHARsQRA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrudduvddghedvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvfevufgtsehmtderreerredtnecuhfhrohhmpedfgfhu lhgvrhcuvfgrvhgvihhrrgdfuceovghulhgvrhesvghulhgvrhhtohdrtghomheqnecugg ftrfgrthhtvghrnhepuefhjeefudeffeeugfehteelvdegkeekueeuudevgfduhfelgffh leeuhedtiefhnecuffhomhgrihhnpegvnhhtvghrphhrihhsvggusgdrtghomhenucevlh hushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegvuhhlvghrsegv uhhlvghrthhordgtohhm X-ME-Proxy: Feedback-ID: i0c21471d:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id 62AE515A0092; Mon, 25 Mar 2024 22:54:10 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.11.0-alpha0-328-gc998c829b7-fm-20240325.002-gc998c829 MIME-Version: 1.0 Message-Id: In-Reply-To: References: <9a9c7e65-c47b-4400-a63e-ac6169c0860e@app.fastmail.com> <40595e73-c7e1-463a-b8be-49792e870007@app.fastmail.com> <6423dfeb-a729-45d3-b71e-7bf1b3adb0c9@enterprisedb.com> <2f0b73f3-e7c0-4e95-9712-1993442a6b64@app.fastmail.com> <34637e7f-0330-420d-8f45-1d022962d2fe@app.fastmail.com> <7a970912-0b77-4942-84f7-2c9ca0bc05a5@eisentraut.org> <44de4e04-db22-40ed-8ba9-46387dc8bf83@app.fastmail.com> <3fa9ef0f-b277-4c13-850a-8ccc04de1406@eisentraut.org> <65b841a8-0c2f-4953-b9cd-240fce84b90b@eisentraut.org> Date: Mon, 25 Mar 2024 23:53:21 -0300 From: "Euler Taveira" To: "kuroda.hayato@fujitsu.com" , "Peter Eisentraut" , "Bharath Rupireddy" Cc: "Amit Kapila" , "Shlok Kyal" , "Tomas Vondra" , "pgsql-hackers@lists.postgresql.org" , "Michael Paquier" , "Andres Freund" , "Ashutosh Bapat" , =?UTF-8?Q?Fabr=C3=ADzio_de_Royes_Mello?= , "vignesh C" Subject: Re: speed up a logical replica setup Content-Type: multipart/mixed; boundary=388d5bf5fe4b41529b2dfc14dd2333aa List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --388d5bf5fe4b41529b2dfc14dd2333aa Content-Type: multipart/alternative; boundary=fe43dc9ea4534fa4a660bf995b6b6e76 --fe43dc9ea4534fa4a660bf995b6b6e76 Content-Type: text/plain On Mon, Mar 25, 2024, at 1:06 PM, Hayato Kuroda (Fujitsu) wrote: > ## Analysis for failure 1 > > The failure caused by a time lag between walreceiver finishes and pg_is_in_recovery() > returns true. > > According to the output [1], it seems that the tool failed at wait_for_end_recovery() > with the message "standby server disconnected from the primary". Also, lines > "redo done at..." and "terminating walreceiver process due to administrator command" > meant that walreceiver was requested to shut down by XLogShutdownWalRcv(). > > According to the source, we confirm that walreceiver is shut down in > StartupXLOG()->FinishWalRecovery()->XLogShutdownWalRcv(). Also, SharedRecoveryState > is changed to RECOVERY_STATE_DONE (this meant the pg_is_in_recovery() return true) > at the latter part of StartupXLOG(). > > So, if there is a delay between FinishWalRecovery() and change the state, the check > in wait_for_end_recovery() would be failed during the time. Since we allow to miss > the walreceiver 10 times and it is checked once per second, the failure occurs if > the time lag is longer than 10 seconds. > > I do not have a good way to fix it. One approach is make NUM_CONN_ATTEMPTS larger, > but it's not a fundamental solution. I was expecting that slow hosts might have issues in wait_for_end_recovery(). As you said it took a lot of steps between FinishWalRecovery() (where walreceiver is shutdown -- XLogShutdownWalRcv) and SharedRecoveryState is set to RECOVERY_STATE_DONE. If this window takes longer than NUM_CONN_ATTEMPTS * WAIT_INTERVAL (10 seconds), it aborts the execution. That's a bad decision because it already finished the promotion and it is just doing the final preparation for the host to become a primary. /* * If it is still in recovery, make sure the target server is * connected to the primary so it can receive the required WAL to * finish the recovery process. If it is disconnected try * NUM_CONN_ATTEMPTS in a row and bail out if not succeed. */ res = PQexec(conn, "SELECT 1 FROM pg_catalog.pg_stat_wal_receiver"); if (PQntuples(res) == 0) { if (++count > NUM_CONN_ATTEMPTS) { stop_standby_server(subscriber_dir); pg_log_error("standby server disconnected from the primary"); break; } } else count = 0; /* reset counter if it connects again */ This code was add to defend against the death/crash of the target server. There are at least 3 options: (1) increase NUM_CONN_ATTEMPTS * WAIT_INTERVAL seconds. We discussed this constant and I decided to use 10 seconds because even in some slow hosts, this time wasn't reached during my tests. It seems I forgot to test the combination of slow host, asserts enabled, and ubsan. I didn't notice that pg_promote() uses 60 seconds as default wait. Maybe that's a reasonable value. I checked the 004_timeline_switch test and the last run took: 39.2s (serinus), 33.1s (culicidae), 18.31s (calliphoridae) and 27.52s (olingo). (2) check if the primary is not running when walreceiver is not available on the target server. Increase the connection attempts iif the primary is not running. Hence, the described case doesn't cause an increment on the count variable. (3) set recovery_timeout default to != 0 and remove pg_stat_wal_receiver check protection against the death/crash target server. I explained in a previous message that timeout may occur in cases that WAL replay to reach consistent state takes more than recovery-timeout seconds. Option (1) is the easiest fix, however, we can have the same issue again if a slow host decides to be even slower, hence, we have to adjust this value again. Option (2) interprets the walreceiver absence as a recovery end and if the primary server is running it can indicate that the target server is in the imminence of the recovery end. Option (3) is not as resilient as the other options. The first patch implements a combination of (1) and (2). > ## Analysis for failure 2 > > According to [2], the physical replication slot which is specified as primary_slot_name > was not used by the walsender process. At that time walsender has not existed. > > ``` > ... > pg_createsubscriber: publisher: current wal senders: 0 > pg_createsubscriber: command is: SELECT 1 FROM pg_catalog.pg_replication_slots WHERE active AND slot_name = 'physical_slot' > pg_createsubscriber: error: could not obtain replication slot information: got 0 rows, expected 1 row > ... > ``` > > Currently standby must be stopped before the command and current code does not > block the flow to ensure the replication is started. So there is a possibility > that the checking is run before walsender is launched. > > One possible approach is to wait until the replication starts. Alternative one is > to ease the condition. That's my suggestion too. I reused NUM_CONN_ATTEMPTS (that was renamed to NUM_ATTEMPTS in the first patch). See second patch. -- Euler Taveira EDB https://www.enterprisedb.com/ --fe43dc9ea4534fa4a660bf995b6b6e76 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
On Mon, Mar 25,= 2024, at 1:06 PM, Hayato Kuroda (Fujitsu) wrote:
## Analysis for failure 1

The failure caused by a time lag between walreceiv= er finishes and pg_is_in_recovery()
returns true.

According to the output [1], it seems that the tool= failed at wait_for_end_recovery()
with the message "stand= by server disconnected from the primary". Also, lines
"red= o done at..." and "terminating walreceiver process due to administrator = command"
meant that walreceiver was requested to shut down= by XLogShutdownWalRcv().

According to the = source, we confirm that walreceiver is shut down in
Startu= pXLOG()->FinishWalRecovery()->XLogShutdownWalRcv(). Also, SharedRe= coveryState
is changed to RECOVERY_STATE_DONE (this meant = the pg_is_in_recovery() return true)
at the latter part of= StartupXLOG().

So, if there is a delay bet= ween FinishWalRecovery() and change the state, the check
i= n wait_for_end_recovery() would be failed during the time. Since we allo= w to miss
the walreceiver 10 times and it is checked once = per second, the failure occurs if
the time lag is longer t= han 10 seconds.

I do not have a good way to= fix it. One approach is make NUM_CONN_ATTEMPTS larger,
bu= t it's not a fundamental solution.

=
I was expecting that slow hosts might have issues in wait_for_end_r= ecovery().
As you said it took a lot of steps between Fini= shWalRecovery() (where
walreceiver is shutdown -- XLogShut= downWalRcv) and SharedRecoveryState is set to
RECOVERY_STA= TE_DONE. If this window takes longer than NUM_CONN_ATTEMPTS *
<= div>WAIT_INTERVAL (10 seconds), it aborts the execution. That's a bad de= cision
because it already finished the promotion and it is= just doing the final
preparation for the host to become a= primary.

     &nb= sp;  /*   
    &nb= sp;    * If it is still in recovery, make sure the target= server is
        = ; * connected to the primary so it can receive the required WAL to
         * finish the r= ecovery process. If it is disconnected try
  &nb= sp;      * NUM_CONN_ATTEMPTS in a row and bail = out if not succeed.
      &n= bsp;  */
        r= es =3D PQexec(conn,
      &n= bsp;           &n= bsp;  "SELECT 1 FROM pg_catalog.pg_stat_wal_receiver");
        if (PQntuples(res) =3D=3D = 0)
        {
<= div>            i= f (++count > NUM_CONN_ATTEMPTS)
    = ;        {
  =             =   stop_standby_server(subscriber_dir);
  &n= bsp;           &n= bsp; pg_log_error("standby server disconnected from the primary");
          &nb= sp;     break;
    = ;        }    
        }
&= nbsp;       else
  = ;          count =3D 0;&nbs= p;         /* reset counter if i= t connects again */

This code was add to de= fend against the death/crash of the target server. There
a= re at least 3 options:

(1) increase NUM_CON= N_ATTEMPTS * WAIT_INTERVAL seconds. We discussed this constant
=
and I decided to use 10 seconds because even in some slow hosts, th= is time
wasn't reached during my tests. It seems I forgot = to test the combination of slow
host, asserts enabled, and= ubsan. I didn't notice that pg_promote() uses 60
seconds = as default wait. Maybe that's a reasonable value. I checked the
004_timeline_switch test and the last run took: 39.2s (serinus), 3= 3.1s
(culicidae), 18.31s (calliphoridae) and 27.52s (oling= o).

(2) check if the primary is not running= when walreceiver is not available on the
target server. I= ncrease the connection attempts iif the primary is not running.
Hence, the described case doesn't cause an increment on the count = variable.

(3) set recovery_timeout default = to !=3D 0 and remove pg_stat_wal_receiver check
protection= against the death/crash target server. I explained in a previous
message that timeout may occur in cases that WAL replay to reach= consistent
state takes more than recovery-timeout seconds= .

Option (1) is the easiest fix, however, w= e can have the same issue again if a
slow host decides to = be even slower, hence, we have to adjust this value again.
Option (2) interprets the walreceiver absence as a recovery end and if = the
primary server is running it can indicate that the tar= get server is in the
imminence of the recovery end. Option= (3) is not as resilient as the other
options.

The first patch implements a combination of (1) and (2= ).

## Analysis for failure 2

According = to [2], the physical replication slot which is specified as primary_slot= _name
was not used by the walsender process. At that time = walsender has not existed.

```
...
pg_createsubscriber: publisher: current wal senders:= 0
pg_createsubscriber: command is: SELECT 1 FROM pg_catal= og.pg_replication_slots WHERE active AND slot_name =3D 'physical_slot'
pg_createsubscriber: error: could not obtain replication sl= ot information: got 0 rows, expected 1 row
...
```

Currently standby must be stopped be= fore the command and current code does not
block the flow = to ensure the replication is started. So there is a possibility
that the checking is run before walsender is launched.

One possible approach is to wait until the replication= starts. Alternative one is
to ease the condition.

That's my suggestion too. I reused NU= M_CONN_ATTEMPTS (that was renamed to
NUM_ATTEMPTS in the f= irst patch). See second patch.


--
Euler Taveira
EDB &nb= sp; https://www.enterprisedb.c= om/

--fe43dc9ea4534fa4a660bf995b6b6e76-- --388d5bf5fe4b41529b2dfc14dd2333aa Content-Disposition: attachment; filename*0="v1-0001-Improve-the-code-that-checks-if-the-recovery-is-f.pat"; filename*1="ch" Content-Type: text/x-patch; name="=?UTF-8?Q?v1-0001-Improve-the-code-that-checks-if-the-recovery-is-f.patc?= =?UTF-8?Q?h?=" Content-Transfer-Encoding: BASE64 RnJvbSBiMmNmYTEzNjI3YmQ4NDRiMjhmZTA1MGZmYjM1ZThiOTY5NmZkZjJlIE1vbiBTZXAg MTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBFdWxlciBUYXZlaXJhIDxldWxlci50YXZlaXJhQGVu dGVycHJpc2VkYi5jb20+CkRhdGU6IE1vbiwgMjUgTWFyIDIwMjQgMjI6MDE6NTIgLTAzMDAK U3ViamVjdDogW1BBVENIIHYxIDEvMl0gSW1wcm92ZSB0aGUgY29kZSB0aGF0IGNoZWNrcyBp ZiB0aGUgcmVjb3ZlcnkgaXMKIGZpbmlzaGluZwoKVGhlIHJlY292ZXJ5IHByb2Nlc3MgaGFz IGEgd2luZG93IGJldHdlZW4gdGhlIHdhbHJlY2VpdmVyIHNodXRkb3duIGFuZAp0aGUgcGdf aXNfaW5fcmVjb3ZlcnkgZnVuY3Rpb24gcmV0dXJucyBmYWxzZS4gSXQgbWVhbnMgdGhhdCB0 aGUKcGdfc3RhdF93YWxfcmVjZWl2ZXIgY2hlY2tzIGNhbiBjYXVzZSB0aGUgc2VydmVyIHRv IGZpbmlzaCB0aGUgcmVjb3ZlcnkKKGV2ZW4gaWYgaXQgYWxyZWFkeSByZWFjaGVzIHRoZSBy ZWNvdmVyeSB0YXJnZXQpLiBTaW5jZSBpdCBjaGVja3MgdGhlCnBnX3N0YXRfd2FsX3JlY2Vp dmVyIHRvIHZlcmlmeSB0aGUgcHJpbWFyeSBpcyBhdmFpbGFibGUsIGlmIGl0IGRvZXMgbm90 CnJldHVybiBhIHJvdywgUFFwaW5nIHRoZSBwcmltYXJ5IHNlcnZlci4gSWYgaXQgaXMgdXAg YW5kIHJ1bm5pbmcsIGl0CmNhbiBpbmRpY2F0ZSB0aGF0IHRoZSB0YXJnZXQgc2VydmVyIGlz IGZpbmlzaGluZyB0aGUgcmVjb3ZlcnkgcHJvY2VzcywKaGVuY2UsIHdlIHNob3VsZG4ndCBj b3VudCBpdCBhcyBhbiBhdHRlbXB0LiBJdCBhdm9pZHMgcHJlbWF0dXJlIGZhaWx1cmVzCm9u IHNsb3cgaG9zdHMuCgpXaGlsZSBvbiBpdCwgaW5jcmVhc2UgdGhlIG51bWJlciBvZiBhdHRl bXB0cyAoMTAgdG8gNjApLiBUaGUgd2FpdCB0aW1lIGlzCnRoZSBzYW1lIHBnX3Byb21vdGUg ZnVuY3Rpb24gdXNlcyBieSBkZWZhdWx0LgotLS0KIHNyYy9iaW4vcGdfYmFzZWJhY2t1cC9w Z19jcmVhdGVzdWJzY3JpYmVyLmMgfCAzMCArKysrKysrKysrKysrLS0tLS0tLS0KIDEgZmls ZSBjaGFuZ2VkLCAxOSBpbnNlcnRpb25zKCspLCAxMSBkZWxldGlvbnMoLSkKCmRpZmYgLS1n aXQgYS9zcmMvYmluL3BnX2Jhc2ViYWNrdXAvcGdfY3JlYXRlc3Vic2NyaWJlci5jIGIvc3Jj L2Jpbi9wZ19iYXNlYmFja3VwL3BnX2NyZWF0ZXN1YnNjcmliZXIuYwppbmRleCBiOGY4MjY5 MzQwLi5jY2E5M2Q4YzI1IDEwMDY0NAotLS0gYS9zcmMvYmluL3BnX2Jhc2ViYWNrdXAvcGdf Y3JlYXRlc3Vic2NyaWJlci5jCisrKyBiL3NyYy9iaW4vcGdfYmFzZWJhY2t1cC9wZ19jcmVh dGVzdWJzY3JpYmVyLmMKQEAgLTMwLDYgKzMwLDggQEAKIAogI2RlZmluZQlERUZBVUxUX1NV Ql9QT1JUCSI1MDQzMiIKIAorI2RlZmluZSBOVU1fQVRURU1QVFMJCTYwCisKIC8qIENvbW1h bmQtbGluZSBvcHRpb25zICovCiBzdHJ1Y3QgQ3JlYXRlU3Vic2NyaWJlck9wdGlvbnMKIHsK QEAgLTkzLDcgKzk1LDcgQEAgc3RhdGljIHZvaWQgcGdfY3RsX3N0YXR1cyhjb25zdCBjaGFy ICpwZ19jdGxfY21kLCBpbnQgcmMpOwogc3RhdGljIHZvaWQgc3RhcnRfc3RhbmRieV9zZXJ2 ZXIoY29uc3Qgc3RydWN0IENyZWF0ZVN1YnNjcmliZXJPcHRpb25zICpvcHQsCiAJCQkJCQkJ CSBib29sIHJlc3RyaWN0ZWRfYWNjZXNzKTsKIHN0YXRpYyB2b2lkIHN0b3Bfc3RhbmRieV9z ZXJ2ZXIoY29uc3QgY2hhciAqZGF0YWRpcik7Ci1zdGF0aWMgdm9pZCB3YWl0X2Zvcl9lbmRf cmVjb3ZlcnkoY29uc3QgY2hhciAqY29ubmluZm8sCitzdGF0aWMgdm9pZCB3YWl0X2Zvcl9l bmRfcmVjb3ZlcnkoY29uc3Qgc3RydWN0IExvZ2ljYWxSZXBJbmZvICpkYmluZm8sCiAJCQkJ CQkJCSAgY29uc3Qgc3RydWN0IENyZWF0ZVN1YnNjcmliZXJPcHRpb25zICpvcHQpOwogc3Rh dGljIHZvaWQgY3JlYXRlX3B1YmxpY2F0aW9uKFBHY29ubiAqY29ubiwgc3RydWN0IExvZ2lj YWxSZXBJbmZvICpkYmluZm8pOwogc3RhdGljIHZvaWQgZHJvcF9wdWJsaWNhdGlvbihQR2Nv bm4gKmNvbm4sIHN0cnVjdCBMb2dpY2FsUmVwSW5mbyAqZGJpbmZvKTsKQEAgLTEzNTQsMTgg KzEzNTYsMTYgQEAgc3RvcF9zdGFuZGJ5X3NlcnZlcihjb25zdCBjaGFyICpkYXRhZGlyKQog ICogdGhlIHJlY292ZXJ5IHByb2Nlc3MuIEJ5IGRlZmF1bHQsIGl0IHdhaXRzIGZvcmV2ZXIu CiAgKi8KIHN0YXRpYyB2b2lkCi13YWl0X2Zvcl9lbmRfcmVjb3ZlcnkoY29uc3QgY2hhciAq Y29ubmluZm8sIGNvbnN0IHN0cnVjdCBDcmVhdGVTdWJzY3JpYmVyT3B0aW9ucyAqb3B0KQor d2FpdF9mb3JfZW5kX3JlY292ZXJ5KGNvbnN0IHN0cnVjdCBMb2dpY2FsUmVwSW5mbyAqZGJp bmZvLCBjb25zdCBzdHJ1Y3QgQ3JlYXRlU3Vic2NyaWJlck9wdGlvbnMgKm9wdCkKIHsKIAlQ R2Nvbm4JICAgKmNvbm47CiAJaW50CQkJc3RhdHVzID0gUE9TVE1BU1RFUl9TVElMTF9TVEFS VElORzsKIAlpbnQJCQl0aW1lciA9IDA7CiAJaW50CQkJY291bnQgPSAwOwkJLyogbnVtYmVy IG9mIGNvbnNlY3V0aXZlIGNvbm5lY3Rpb24gYXR0ZW1wdHMgKi8KIAotI2RlZmluZSBOVU1f Q09OTl9BVFRFTVBUUwkxMAotCiAJcGdfbG9nX2luZm8oIndhaXRpbmcgZm9yIHRoZSB0YXJn ZXQgc2VydmVyIHRvIHJlYWNoIHRoZSBjb25zaXN0ZW50IHN0YXRlIik7CiAKLQljb25uID0g Y29ubmVjdF9kYXRhYmFzZShjb25uaW5mbywgdHJ1ZSk7CisJY29ubiA9IGNvbm5lY3RfZGF0 YWJhc2UoZGJpbmZvLT5zdWJjb25uaW5mbywgdHJ1ZSk7CiAKIAlmb3IgKDs7KQogCXsKQEAg LTEzODQsMTYgKzEzODQsMjQgQEAgd2FpdF9mb3JfZW5kX3JlY292ZXJ5KGNvbnN0IGNoYXIg KmNvbm5pbmZvLCBjb25zdCBzdHJ1Y3QgQ3JlYXRlU3Vic2NyaWJlck9wdGlvbnMKIAkJfQog CiAJCS8qCi0JCSAqIElmIGl0IGlzIHN0aWxsIGluIHJlY292ZXJ5LCBtYWtlIHN1cmUgdGhl IHRhcmdldCBzZXJ2ZXIgaXMKLQkJICogY29ubmVjdGVkIHRvIHRoZSBwcmltYXJ5IHNvIGl0 IGNhbiByZWNlaXZlIHRoZSByZXF1aXJlZCBXQUwgdG8KLQkJICogZmluaXNoIHRoZSByZWNv dmVyeSBwcm9jZXNzLiBJZiBpdCBpcyBkaXNjb25uZWN0ZWQgdHJ5Ci0JCSAqIE5VTV9DT05O X0FUVEVNUFRTIGluIGEgcm93IGFuZCBiYWlsIG91dCBpZiBub3Qgc3VjY2VlZC4KKwkJICog SWYgaXQgaXMgc3RpbGwgaW4gcmVjb3ZlcnksIG1ha2Ugc3VyZSB0aGUgdGFyZ2V0IHNlcnZl ciBpcyBjb25uZWN0ZWQKKwkJICogdG8gdGhlIHByaW1hcnkgc28gaXQgY2FuIHJlY2VpdmUg dGhlIHJlcXVpcmVkIFdBTCB0byBmaW5pc2ggdGhlCisJCSAqIHJlY292ZXJ5IHByb2Nlc3Mu IElmIHRoZSB3YWxyZWNlaXZlciBwcm9jZXNzIGlzIG5vdCBydW5uaW5nIGl0CisJCSAqIHNo b3VsZCBpbmRpY2F0ZSB0aGF0IChpKSB0aGUgcmVjb3ZlcnkgaXMgYWxtb3N0IGZpbmlzaGVk IG9yIChpaSkgdGhlCisJCSAqIHByaW1hcnkgaXMgbm90IHJ1bm5pbmcgb3IgaXMgbm90IGFj Y3BldGluZyBjb25uZWN0aW9ucy4gSXQgc2hvdWxkCisJCSAqIGNvdW50IGFzIGF0dGVtcHRz IGlpZiAoaWkpIGlzIHRydWUuIEluIHRoaXMgY2FzZSwgdHJ5IE5VTV9BVFRFTVBUUworCQkg KiBpbiBhIHJvdyBhbmQgYmFpbCBvdXQgaWYgbm90IHN1Y2NlZWQuCiAJCSAqLwogCQlyZXMg PSBQUWV4ZWMoY29ubiwKIAkJCQkJICJTRUxFQ1QgMSBGUk9NIHBnX2NhdGFsb2cucGdfc3Rh dF93YWxfcmVjZWl2ZXIiKTsKIAkJaWYgKFBRbnR1cGxlcyhyZXMpID09IDApCiAJCXsKLQkJ CWlmICgrK2NvdW50ID4gTlVNX0NPTk5fQVRURU1QVFMpCisJCQlpZiAoUFFwaW5nKGRiaW5m by0+cHViY29ubmluZm8pICE9IFBRUElOR19PSykKKwkJCQljb3VudCsrOworCQkJZWxzZQor CQkJCWNvdW50ID0gMDsJCS8qIHJlc2V0IGNvdW50ZXIgaWYgaXQgY29ubmVjdHMgYWdhaW4g Ki8KKworCQkJaWYgKGNvdW50ID4gTlVNX0FUVEVNUFRTKQogCQkJewogCQkJCXN0b3Bfc3Rh bmRieV9zZXJ2ZXIoc3Vic2NyaWJlcl9kaXIpOwogCQkJCXBnX2xvZ19lcnJvcigic3RhbmRi eSBzZXJ2ZXIgZGlzY29ubmVjdGVkIGZyb20gdGhlIHByaW1hcnkiKTsKQEAgLTIxMTMsNyAr MjEyMSw3IEBAIG1haW4oaW50IGFyZ2MsIGNoYXIgKiphcmd2KQogCXN0YXJ0X3N0YW5kYnlf c2VydmVyKCZvcHQsIHRydWUpOwogCiAJLyogV2FpdGluZyB0aGUgc3Vic2NyaWJlciB0byBi ZSBwcm9tb3RlZCAqLwotCXdhaXRfZm9yX2VuZF9yZWNvdmVyeShkYmluZm9bMF0uc3ViY29u bmluZm8sICZvcHQpOworCXdhaXRfZm9yX2VuZF9yZWNvdmVyeSgmZGJpbmZvWzBdLCAmb3B0 KTsKIAogCS8qCiAJICogQ3JlYXRlIHRoZSBzdWJzY3JpcHRpb24gZm9yIGVhY2ggZGF0YWJh c2Ugb24gc3Vic2NyaWJlci4gSXQgZG9lcyBub3QKLS0gCjIuMzAuMgoK --388d5bf5fe4b41529b2dfc14dd2333aa Content-Disposition: attachment; filename*0="v1-0002-Improve-the-code-that-checks-if-the-primary-slot-.pat"; filename*1="ch" Content-Type: text/x-patch; name="=?UTF-8?Q?v1-0002-Improve-the-code-that-checks-if-the-primary-slot-.patc?= =?UTF-8?Q?h?=" Content-Transfer-Encoding: BASE64 RnJvbSA4NzI1MTBlZDY3YjkxY2I3NDgyZGVhM2JjZTgzMTU0OWQzNTE5ZTgwIE1vbiBTZXAg MTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBFdWxlciBUYXZlaXJhIDxldWxlci50YXZlaXJhQGVu dGVycHJpc2VkYi5jb20+CkRhdGU6IE1vbiwgMjUgTWFyIDIwMjQgMjM6MjU6MzAgLTAzMDAK U3ViamVjdDogW1BBVENIIHYxIDIvMl0gSW1wcm92ZSB0aGUgY29kZSB0aGF0IGNoZWNrcyBp ZiB0aGUgcHJpbWFyeSBzbG90IGlzCiBhdmFpbGFibGUKClRoZSB0YXJnZXQgc2VydmVyIGlz IHN0YXJ0ZWQgYSBmZXcgaW5zdHJ1Y3Rpb25zIGJlZm9yZSBjaGVja2luZyB0aGUKcHJpbWFy eSBzZXJ2ZXIgYW5kIHRoZSByZXBsaWNhdGlvbiBzbG90IG1pZ2h0IG5vdCBiZSBhY3RpdmUu IEluc3RlYWQgb2YKZmFpbGluZyB0aGUgZmlyc3QgdGltZSwgdHJ5IGEgZmV3IHRpbWVzLgot LS0KIHNyYy9iaW4vcGdfYmFzZWJhY2t1cC9wZ19jcmVhdGVzdWJzY3JpYmVyLmMgfCAzNSAr KysrKysrKysrKysrKystLS0tLS0KIDEgZmlsZSBjaGFuZ2VkLCAyNSBpbnNlcnRpb25zKCsp LCAxMCBkZWxldGlvbnMoLSkKCmRpZmYgLS1naXQgYS9zcmMvYmluL3BnX2Jhc2ViYWNrdXAv cGdfY3JlYXRlc3Vic2NyaWJlci5jIGIvc3JjL2Jpbi9wZ19iYXNlYmFja3VwL3BnX2NyZWF0 ZXN1YnNjcmliZXIuYwppbmRleCBjY2E5M2Q4YzI1Li5mMTdlOWJkZTljIDEwMDY0NAotLS0g YS9zcmMvYmluL3BnX2Jhc2ViYWNrdXAvcGdfY3JlYXRlc3Vic2NyaWJlci5jCisrKyBiL3Ny Yy9iaW4vcGdfYmFzZWJhY2t1cC9wZ19jcmVhdGVzdWJzY3JpYmVyLmMKQEAgLTg4Nyw2ICs4 ODcsOCBAQCBjaGVja19wdWJsaXNoZXIoY29uc3Qgc3RydWN0IExvZ2ljYWxSZXBJbmZvICpk YmluZm8pCiAJewogCQlQUUV4cEJ1ZmZlciBzdHIgPSBjcmVhdGVQUUV4cEJ1ZmZlcigpOwog CQljaGFyCSAgICpwc25fZXNjID0gUFFlc2NhcGVMaXRlcmFsKGNvbm4sIHByaW1hcnlfc2xv dF9uYW1lLCBzdHJsZW4ocHJpbWFyeV9zbG90X25hbWUpKTsKKwkJaW50CQkJbnR1cGxlczsK KwkJaW50CQkJY291bnQgPSAwOwogCiAJCWFwcGVuZFBRRXhwQnVmZmVyKHN0ciwKIAkJCQkJ CSAgIlNFTEVDVCAxIEZST00gcGdfY2F0YWxvZy5wZ19yZXBsaWNhdGlvbl9zbG90cyAiCkBA IC04OTcsMjUgKzg5OSwzOCBAQCBjaGVja19wdWJsaXNoZXIoY29uc3Qgc3RydWN0IExvZ2lj YWxSZXBJbmZvICpkYmluZm8pCiAKIAkJcGdfbG9nX2RlYnVnKCJjb21tYW5kIGlzOiAlcyIs IHN0ci0+ZGF0YSk7CiAKLQkJcmVzID0gUFFleGVjKGNvbm4sIHN0ci0+ZGF0YSk7Ci0JCWlm IChQUXJlc3VsdFN0YXR1cyhyZXMpICE9IFBHUkVTX1RVUExFU19PSykKKwkJLyoKKwkJICog VGhlIHJlcGxpY2F0aW9uIHNsb3QgbWlnaHQgdGFrZSBzb21lIHRpbWUgdG8gYmUgYWN0aXZl LCB0cnkgYSBmZXcKKwkJICogdGltZXMgaWYgbmVjZXNzYXJ5LgorCQkgKi8KKwkJZG8KIAkJ ewotCQkJcGdfbG9nX2Vycm9yKCJjb3VsZCBub3Qgb2J0YWluIHJlcGxpY2F0aW9uIHNsb3Qg aW5mb3JtYXRpb246ICVzIiwKLQkJCQkJCSBQUXJlc3VsdEVycm9yTWVzc2FnZShyZXMpKTsK LQkJCWRpc2Nvbm5lY3RfZGF0YWJhc2UoY29ubiwgdHJ1ZSk7Ci0JCX0KKwkJCXJlcyA9IFBR ZXhlYyhjb25uLCBzdHItPmRhdGEpOworCQkJaWYgKFBRcmVzdWx0U3RhdHVzKHJlcykgIT0g UEdSRVNfVFVQTEVTX09LKQorCQkJeworCQkJCXBnX2xvZ19lcnJvcigiY291bGQgbm90IG9i dGFpbiByZXBsaWNhdGlvbiBzbG90IGluZm9ybWF0aW9uOiAlcyIsCisJCQkJCQkJIFBRcmVz dWx0RXJyb3JNZXNzYWdlKHJlcykpOworCQkJCWRpc2Nvbm5lY3RfZGF0YWJhc2UoY29ubiwg dHJ1ZSk7CisJCQl9CiAKLQkJaWYgKFBRbnR1cGxlcyhyZXMpICE9IDEpCisJCQludHVwbGVz ID0gUFFudHVwbGVzKHJlcyk7CisJCQlQUWNsZWFyKHJlcyk7CisKKwkJCWlmIChudHVwbGVz ID09IDEpCS8qIHJlcGxpY2F0aW9uIHNsb3QgaXMgYWxyZWFkeSBhY3RpdmUgKi8KKwkJCQli cmVhazsKKwkJCWVsc2UKKwkJCQljb3VudCsrOworCQl9IHdoaWxlIChjb3VudCA+IE5VTV9B VFRFTVBUUyk7CisKKwkJaWYgKG50dXBsZXMgIT0gMSkKIAkJewogCQkJcGdfbG9nX2Vycm9y KCJjb3VsZCBub3Qgb2J0YWluIHJlcGxpY2F0aW9uIHNsb3QgaW5mb3JtYXRpb246IGdvdCAl ZCByb3dzLCBleHBlY3RlZCAlZCByb3ciLAotCQkJCQkJIFBRbnR1cGxlcyhyZXMpLCAxKTsK KwkJCQkJCSBudHVwbGVzLCAxKTsKIAkJCWRpc2Nvbm5lY3RfZGF0YWJhc2UoY29ubiwgdHJ1 ZSk7CiAJCX0KIAkJZWxzZQogCQkJcGdfbG9nX2luZm8oInByaW1hcnkgaGFzIHJlcGxpY2F0 aW9uIHNsb3QgXCIlc1wiIiwKIAkJCQkJCXByaW1hcnlfc2xvdF9uYW1lKTsKLQotCQlQUWNs ZWFyKHJlcyk7CiAJfQogCiAJZGlzY29ubmVjdF9kYXRhYmFzZShjb25uLCBmYWxzZSk7Ci0t IAoyLjMwLjIKCg== --388d5bf5fe4b41529b2dfc14dd2333aa--