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.96) (envelope-from ) id 1vgCs2-009Or4-2R for pgsql-hackers@arkaria.postgresql.org; Thu, 15 Jan 2026 02:13:59 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vgCs1-00E6K2-33 for pgsql-hackers@arkaria.postgresql.org; Thu, 15 Jan 2026 02:13:58 +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.96) (envelope-from ) id 1vgCs1-00E6Jb-1v for pgsql-hackers@lists.postgresql.org; Thu, 15 Jan 2026 02:13:57 +0000 Received: from mail-lj1-x22b.google.com ([2a00:1450:4864:20::22b]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1vgCrz-000XKW-1w for pgsql-hackers@lists.postgresql.org; Thu, 15 Jan 2026 02:13:57 +0000 Received: by mail-lj1-x22b.google.com with SMTP id 38308e7fff4ca-38320cd563aso5047461fa.0 for ; Wed, 14 Jan 2026 18:13:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1768443234; x=1769048034; darn=lists.postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Yfp4zm9i1LEcOgx6AQV21LKeXVL/P7stvN1UJ7zyg+U=; b=f3qMHv/0RH3NWjvDtMRMuKFadp7TdARkyTqijPulc78Wu2aamQMnkV/CFPmld1w7/o qa+nOgiSX8f/wGvyZYqDXRXNIa+WUEa2wCpr1W3q7WI0dp2sdCAVAgcnXFbqUhDMkQGJ 1Rs8rGbHEIm0FeD4mDTmCAJ0g8vJNB4ucz1hHtCQaCGPbS81F5xxw4VdoD4R72931v/e xQG29xZfpFpQB++12uqC0U24rTQI16KxqgZG6ipSevuxXUwmwtZMmpqZhwyq/+I7gIg+ zg00qBTm/78jezazCZ56vbGT4iSWQiIYUeA0GiOcKgUhpL5jKgteCnTICa/9X5fFq7sI SVgg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768443234; x=1769048034; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=Yfp4zm9i1LEcOgx6AQV21LKeXVL/P7stvN1UJ7zyg+U=; b=gA5kYJAdFwicRY8n1ymXz/KZCD03r4tjQuq7M4R13tTypJnp4YaiQT/Ler3pLw9anH DzVV9vXGCluw7Q1LW8DoLaBaeBnAUXjUth7OGxrVU6OtnCLzBpX2zMhxfSesKMaj1Nm9 tKvnl8SI518xMt5nPaBhSraLLVstHk2yfgu1vock/mXdLOPMc032Rz9cGVkRyubik2FB ZV3PDhG5PG2CHSumUGVXeMtKHlYhHNK/2DETHhl0HgdnYVfgyYmpTW2QM7Vm+MCwUIzK /DaNao55hZHKakAjMY4TrLvyPh0qX6YVT/95tu9Dis6brfJvG/SeNSYPV3oiIfSYxsXP lyYA== X-Forwarded-Encrypted: i=1; AJvYcCVSoYsNjhZwgNbUrFgbF/0kp+y2yv9gcJFnQ9Dpg3aJd4JCYncmqhmLMJRXbPynu+1YDjOXkeIKUxRHmgnA@lists.postgresql.org X-Gm-Message-State: AOJu0YzDVgbCmZuYNBcN0SN6LX/ace8w2HUh2lNnlmSr0PSNHhvqM9B8 Ui30NKRpdwpzF4ymZrVKCgjLW74/q53OabO5Oo3l/PCUiahsJMKNkbN6ri4vUnFQ2Cq4e3AiZpS U80Bt1fUPGtQjj+2Geu7V2v+MUVv+gMg= X-Gm-Gg: AY/fxX7xjNcMQm4lRTo910BQhJX47NPqWpRczNLFZ3fxBV0zHWqqJXj9LA66IYs7wtP Huq8M9gG1f9vaR+6AbDpB1VwOCYiRva3Dk+34MoS9MHdTy7q0CczG2KppnZatv8hXW2U2iKWO8i ji8XHJzgN6D+5Uta7uUrNnmg0jwL9oywnWPS25hLbL6KeqLhiYMz8fpRu7gyb2ZG+TlqkgHnYzs /SOyJbLwAFyvtzE9ht9S1AQbWKUlW/JV2UbYljO518d2UKRaB9vl2UgEYzEn0yxZM6vxQxj X-Received: by 2002:a2e:a9a4:0:b0:383:1b7c:6d6a with SMTP id 38308e7fff4ca-3836073f67bmr14326561fa.25.1768443233612; Wed, 14 Jan 2026 18:13:53 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Masahiko Sawada Date: Wed, 14 Jan 2026 18:13:16 -0800 X-Gm-Features: AZwV_Qg18TefVUyVBfErfD0Zj3ncsLt7V-c9jbrjRTcmtWbKgFJqNysgapqtwHI Message-ID: Subject: Re: POC: Parallel processing of indexes in autovacuum To: Daniil Davydov <3danissimo@gmail.com> Cc: Sami Imseih , Alexander Korotkov , Matheus Alcantara , Maxim Orlov , Postgres hackers Content-Type: multipart/mixed; boundary="000000000000bed4e0064863c694" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000bed4e0064863c694 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jan 7, 2026 at 1:51=E2=80=AFAM Daniil Davydov <3danissimo@gmail.com= > wrote: > > Hi, > > On Tue, Jan 6, 2026 at 3:44=E2=80=AFAM Daniil Davydov <3danissimo@gmail.c= om> wrote: > > > > On Tue, Jan 6, 2026 at 1:51=E2=80=AFAM Masahiko Sawada wrote: > > > > > > Are you still working on it? Or shall I draft this part on top of the > > > 0001 patch? > > > > I thought about some "beautiful" approach, but for now I have > > only one idea - force parallel a/v workers to get values for these > > parameters from shmem (which obviously can be modified by the > > leader a/v process). I'll post this patch in the near future. > > > > I am posting a draft version of the patch (see 0005) that allows parallel > leader to propagate changes of cost-based parameters to its parallel > workers. It is a very rough fix, but it reflects my idea that is to have = some > shared state from which parallel workers can get values for the parameter= s > (and which only leader worker can modify, obviously). > > I have also added a test that shows that this idea is working - the test > ensures that parallel workers can change its parameters if they have been > changed for the leader worker. > > Note that so far the work is in progress - this logic works only for > vacuum_cost_delay and vacuum_cost_limits parameters. I think that we > should agree on an idea first, and only then apply logic for all appropri= ate > parameters. > > What do you think? Thank you for updating the patches! Here are review comments. * 0001 patch +static void +autovacuum_worker_before_shmem_exit(int code, Datum arg) +{ + if (code !=3D 0) + AutoVacuumReleaseAllParallelWorkers(); + + Assert(av_nworkers_reserved =3D=3D 0); +} While adding the assertion here makes sense, the assertion won't work in non-assertion builds. I guess it's safer to call AutoVacuumReleaseAllParallelWorkers() regardless of the code to ensure that no autovacuum workers exit while holding parallel workers. --- + before_shmem_exit(autovacuum_worker_before_shmem_exit, 0); I think it would be better to set this callback later like before the main loop of processing the tables as it makes no sense even if we set it very early. --- + /* + * Cap the number of free workers by new parameter's value, if needed. + */ + AutoVacuumShmem->av_freeParallelWorkers =3D + Min(AutoVacuumShmem->av_freeParallelWorkers, + autovacuum_max_parallel_workers); + + if (autovacuum_max_parallel_workers > prev_max_parallel_workers) + { + /* + * If user wants to increase number of parallel autovacuum workers,= we + * must increase number of free workers. + */ + AutoVacuumShmem->av_freeParallelWorkers +=3D + (autovacuum_max_parallel_workers - prev_max_parallel_workers); + } Suppose the previous autovacuum_max_parallel_workers is 5 and there are 2 workers are reserved (i.e., there are 3 free parallel workers), if the autovacuum_max_parallel_workers changes to 2, the new AutoVacuumShmem->av_freeParallelWorkers would be 2 based on the above codes, but I believe that the new number of free workers should be 0 as there are already 2 workers are running. What do you think? I guess we can calculate the new number of free workers by: Max((autovacuum_max_parallel_workers - prev_max_parallel_workers) + AutoVacuumShmem->av_freeParallelWorkers), 0) --- I've attached a patch proposing some minor changes. * 0002 patch + /* + * Number of planned and actually launched parallel workers for all ind= ex + * scans, or NULL + */ + PVWorkersUsage *workers_usage; I think that LVRelState can have PVWorkersUsage instead of a pointer to it. --- + /* + * Allocate space for workers usage statistics. Thus, we explicitly + * make clear that such statistics must be accumulated. For now, th= is + * is used only by autovacuum leader worker, because it must log it= in + * the end of table processing. + */ + vacrel->workers_usage =3D AmAutoVacuumWorkerProcess() ? + (PVWorkersUsage *) palloc0(sizeof(PVWorkersUsage)) : + NULL; I think we can report the worker statistics even in VACUUM VERBOSE logs. Currently VACUUM VERBOSE reports the worker usage just during index vacuuming but it would make sense to report the overall statistics in vacuum logs. It would help make VACUUM VERBOSE logs and autovacuum logs consistent. But we don't need to report the worker usage if we didn't use the parallel vacuum (i.e., if npanned =3D=3D 0). --- + /* Remember these values, if we asked to. */ + if (wusage !=3D NULL) + { + wusage->nlaunched +=3D pvs->pcxt->nworkers_launched; + wusage->nplanned +=3D nworkers; + } This code runs after the attempt to reserve parallel workers. Consequently, if we fail to reserve any workers due to autovacuum_max_parallel_workers, we report the status as if parallel vacuum wasn't planned at all. I think knowing the number of workers that were planned but not reserved would provide valuable insight for users tuning autovacuum_max_parallel_workers. --- + if (vacrel->workers_usage) + appendStringInfo(&buf, + _("parallel index vacuum/cleanup : workers planned =3D %d, workers launched =3D %d\n"), + vacrel->workers_usage->nplanned, + vacrel->workers_usage->nlaunched); Since these numbers are the total number of workers planned and launched, how about changing it to something "parallel index vacuum/cleanup: %d workers were planned and %d workers were launched in total"? * 0003 patch +typedef enum AVLeaderFaulureType +{ + FAIL_NONE, + FAIL_ERROR, + FAIL_FATAL, +} AVLeaderFaulureType; I'm concerned that it is somewhat overwrapped with what injection points does as we can set 'error' to injection_points_attach(). For the FATAL error, we can terminate the autovacuum worker by using pg_terminate_backend() that keeps waiting due to injection_point_attach() with action=3D'wait'. --- + /* + * Injection point to help exercising number of available parallel + * autovacuum workers. + */ + INJECTION_POINT("autovacuum-set-free-parallel-workers-num", + &AutoVacuumShmem->av_freeParallelWorkers); This injection point is added to two places. IIUC the purpose of this function is to update the free_parallel_workers of InjPointState. And that value is taken by get_parallel_autovacuum_free_workers() SQL function during the TAP test. I guess it's better to have get_parallel_autovacuum_free_workers() function to direcly check av_freeParallelWorkers with a proper locking. --- It would be great if we could test the av_freeParallelWorkers adjustment when max_parallel_maintenance_workers changes. * 0005 patch +typedef struct PVSharedCostParams +{ + slock_t spinlock; /* protects all fields below */ + + /* Copies of corresponding parameters from autovacuum leader process */ + double cost_delay; + int cost_limit; +} PVSharedCostParams; Since Parallel workers don't reload the config file I think other vacuum delay related parameters such as VacuumCostPage{Miss|Hit|Dirty} also needs to be shared by the leader. --- + if (!AmAutoVacuumWorkerProcess()) + { + /* + * If we are autovacuum parallel worker, check whether cost-based + * parameters had changed in leader worker. + * If so, vacuum_cost_delay and vacuum_cost_limit will be set to th= e + * values which leader worker is operating on. + * + * Do it before checking VacuumCostActive, because its value might = be + * changed after leader's parameters consumption. + */ + parallel_vacuum_fix_cost_based_params(); + } We need to add checks to prevent the normal backend running the VACUUM command from calling parallel_vacuum_fix_cost_based_params(). IIUC autovacuum parallel workers would call parallel_vacuum_fix_cost_based_params() and update their vacuum_cost_{delay|limit} every vacuum_delay_point(). --- +/* + * Function to be called from parallel autovacuum worker in order to sync + * some cost-based delay parameter with the leader worker. + */ +bool +parallel_vacuum_fix_cost_based_params(void) +{ The 'fix' doesn't sound right to me as it's not broken actually. How about something like parallel_vacuum_update_shared_delay_params? + Assert(IsParallelWorker() && !AmAutoVacuumWorkerProcess()); + + SpinLockAcquire(&pv_shared_cost_params->spinlock); + + vacuum_cost_delay =3D pv_shared_cost_params->cost_delay; + vacuum_cost_limit =3D pv_shared_cost_params->cost_limit; + + SpinLockRelease(&pv_shared_cost_params->spinlock); IIUC autovacuum parallel workers seems to update their vacuum_cost_{delay|limit} every vacuum_delay_point(), which seems not good. Can we somehow avoid unnecessary updates? --- + + if (vacuum_cost_delay > 0 && !VacuumFailsafeActive) + VacuumCostActive =3D true; + Should we consider the case of disabling VacuumCostActive as well? Regards, -- Masahiko Sawada Amazon Web Services: https://aws.amazon.com --000000000000bed4e0064863c694 Content-Type: application/octet-stream; name="0001_masahiko.patch" Content-Disposition: attachment; filename="0001_masahiko.patch" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_mket8ch20 ZGlmZiAtLWdpdCBhL3NyYy9iYWNrZW5kL2NvbW1hbmRzL3ZhY3V1bXBhcmFsbGVsLmMgYi9zcmMv YmFja2VuZC9jb21tYW5kcy92YWN1dW1wYXJhbGxlbC5jCmluZGV4IDZhM2EwMDU4NWY5Li5jYjQy ZDRlNTcyZiAxMDA2NDQKLS0tIGEvc3JjL2JhY2tlbmQvY29tbWFuZHMvdmFjdXVtcGFyYWxsZWwu YworKysgYi9zcmMvYmFja2VuZC9jb21tYW5kcy92YWN1dW1wYXJhbGxlbC5jCkBAIC02NTYsNyAr NjU2LDcgQEAgcGFyYWxsZWxfdmFjdXVtX3Byb2Nlc3NfYWxsX2luZGV4ZXMoUGFyYWxsZWxWYWN1 dW1TdGF0ZSAqcHZzLCBpbnQgbnVtX2luZGV4X3NjYW4KIAlud29ya2VycyA9IE1pbihud29ya2Vy cywgcHZzLT5wY3h0LT5ud29ya2Vycyk7CiAKIAkvKgotCSAqIFJlc2VydmUgd29ya2VycyBpbiBh dXRvdmFjdXVtIGdsb2JhbCBzdGF0ZS4gTm90ZSwgdGhhdCB3ZSBtYXkgYmUgZ2l2ZW4KKwkgKiBS ZXNlcnZlIHdvcmtlcnMgaW4gYXV0b3ZhY3V1bSBnbG9iYWwgc3RhdGUuIE5vdGUgdGhhdCB3ZSBt YXkgYmUgZ2l2ZW4KIAkgKiBmZXdlciB3b3JrZXJzIHRoYW4gd2UgcmVxdWVzdGVkLgogCSAqLwog CWlmIChBbUF1dG9WYWN1dW1Xb3JrZXJQcm9jZXNzKCkgJiYgbndvcmtlcnMgPiAwKQpAQCAtNzA2 LDE1ICs3MDYsMTIgQEAgcGFyYWxsZWxfdmFjdXVtX3Byb2Nlc3NfYWxsX2luZGV4ZXMoUGFyYWxs ZWxWYWN1dW1TdGF0ZSAqcHZzLCBpbnQgbnVtX2luZGV4X3NjYW4KIAogCQlMYXVuY2hQYXJhbGxl bFdvcmtlcnMocHZzLT5wY3h0KTsKIAotCQlpZiAoQW1BdXRvVmFjdXVtV29ya2VyUHJvY2Vzcygp ICYmCi0JCQlwdnMtPnBjeHQtPm53b3JrZXJzX2xhdW5jaGVkIDwgbndvcmtlcnMpCi0JCXsKLQkJ CS8qCi0JCQkgKiBUZWxsIGF1dG92YWN1dW0gdGhhdCB3ZSBjb3VsZCBub3QgbGF1bmNoIGFsbCB0 aGUgcHJldmlvdXNseQotCQkJICogcmVzZXJ2ZWQgd29ya2Vycy4KLQkJCSAqLworCQkvKgorCQkg KiBUZWxsIGF1dG92YWN1dW0gdGhhdCB3ZSBjb3VsZCBub3QgbGF1bmNoIGFsbCB0aGUgcHJldmlv dXNseQorCQkgKiByZXNlcnZlZCB3b3JrZXJzLgorCQkgKi8KKwkJaWYgKEFtQXV0b1ZhY3V1bVdv cmtlclByb2Nlc3MoKSAmJiBwdnMtPnBjeHQtPm53b3JrZXJzX2xhdW5jaGVkIDwgbndvcmtlcnMp CiAJCQlBdXRvVmFjdXVtUmVsZWFzZVBhcmFsbGVsV29ya2Vycyhud29ya2VycyAtIHB2cy0+cGN4 dC0+bndvcmtlcnNfbGF1bmNoZWQpOwotCQl9CiAKIAkJaWYgKHB2cy0+cGN4dC0+bndvcmtlcnNf bGF1bmNoZWQgPiAwKQogCQl7CkBAIC03NjUsNyArNzYyLDcgQEAgcGFyYWxsZWxfdmFjdXVtX3By b2Nlc3NfYWxsX2luZGV4ZXMoUGFyYWxsZWxWYWN1dW1TdGF0ZSAqcHZzLCBpbnQgbnVtX2luZGV4 X3NjYW4KIAkJZm9yIChpbnQgaSA9IDA7IGkgPCBwdnMtPnBjeHQtPm53b3JrZXJzX2xhdW5jaGVk OyBpKyspCiAJCQlJbnN0ckFjY3VtUGFyYWxsZWxRdWVyeSgmcHZzLT5idWZmZXJfdXNhZ2VbaV0s ICZwdnMtPndhbF91c2FnZVtpXSk7CiAKLQkJLyogQWxzbyByZWxlYXNlIGFsbCBwcmV2aW91c2x5 IHJlc2VydmVkIHBhcmFsbGVsIGF1dG92YWN1dW0gd29ya2VycyAqLworCQkvKiBSZWxlYXNlIGFs bCB0aGUgcmVzZXJ2ZWQgcGFyYWxsZWwgd29ya2VycyBmb3IgYXV0b3ZhY3V1bSAqLwogCQlpZiAo QW1BdXRvVmFjdXVtV29ya2VyUHJvY2VzcygpICYmIHB2cy0+cGN4dC0+bndvcmtlcnNfbGF1bmNo ZWQgPiAwKQogCQkJQXV0b1ZhY3V1bVJlbGVhc2VQYXJhbGxlbFdvcmtlcnMocHZzLT5wY3h0LT5u d29ya2Vyc19sYXVuY2hlZCk7CiAJfQpkaWZmIC0tZ2l0IGEvc3JjL2JhY2tlbmQvcG9zdG1hc3Rl ci9hdXRvdmFjdXVtLmMgYi9zcmMvYmFja2VuZC9wb3N0bWFzdGVyL2F1dG92YWN1dW0uYwppbmRl eCBiYzExOTcwYmZlZS4uNmNjYzg4YzRlMWUgMTAwNjQ0Ci0tLSBhL3NyYy9iYWNrZW5kL3Bvc3Rt YXN0ZXIvYXV0b3ZhY3V1bS5jCisrKyBiL3NyYy9iYWNrZW5kL3Bvc3RtYXN0ZXIvYXV0b3ZhY3V1 bS5jCkBAIC0xNTIsOCArMTUyLDkgQEAgc3RhdGljIGRvdWJsZSBhdl9zdG9yYWdlX3BhcmFtX2Nv c3RfZGVsYXkgPSAtMTsKIHN0YXRpYyBpbnQJYXZfc3RvcmFnZV9wYXJhbV9jb3N0X2xpbWl0ID0g LTE7CiAKIC8qCi0gKiBWYXJpYWJsZSB0byBrZWVwIG51bWJlciBvZiBjdXJyZW50bHkgcmVzZXJ2 ZWQgcGFyYWxsZWwgYXV0b3ZhY3V1bSB3b3JrZXJzLgotICogSXQgaXMgb25seSByZWxldmFudCBm b3IgcGFyYWxsZWwgYXV0b3ZhY3V1bSBsZWFkZXIgcHJvY2Vzcy4KKyAqIFRyYWNrcyB0aGUgbnVt YmVyIG9mIHBhcmFsbGVsIHdvcmtlcnMgY3VycmVudGx5IHJlc2VydmVkIGJ5IHRoZQorICogYXV0 b3ZhY3V1bSB3b3JrZXIuIFRoaXMgaXMgbm9uLXplcm8gb25seSBmb3IgdGhlIHBhcmFsbGVsIGF1 dG92YWN1dW0KKyAqIGxlYWRlciBwcm9jZXNzLgogICovCiBzdGF0aWMgaW50CWF2X253b3JrZXJz X3Jlc2VydmVkID0gMDsKIApAQCAtMzQwNywzMyArMzQwOCwyNCBAQCBBdXRvVmFjdXVtUmVxdWVz dFdvcmsoQXV0b1ZhY3V1bVdvcmtJdGVtVHlwZSB0eXBlLCBPaWQgcmVsYXRpb25JZCwKIH0KIAog LyoKLSAqIEluIG9yZGVyIHRvIG1lZXQgdGhlICdhdXRvdmFjdXVtX21heF9wYXJhbGxlbF93b3Jr ZXJzJyBsaW1pdCwgbGVhZGVyCi0gKiBhdXRvdmFjdXVtIHByb2Nlc3MgbXVzdCBjYWxsIHRoaXMg ZnVuY3Rpb24gZHVyaW5nIGNvbXB1dGluZyB0aGUgcGFyYWxsZWwKLSAqIGRlZ3JlZS4KKyAqIFJl c2VydmVzIHBhcmFsbGVsIHdvcmtlcnMgZm9yIGF1dG92YWN1dW0uCiAgKgotICogJ253b3JrZXJz JyBpcyB0aGUgZGVzaXJlZCBudW1iZXIgb2YgcGFyYWxsZWwgd29ya2VycyB0byByZXNlcnZlLiBG dW5jdGlvbgotICogc2V0cyAnbndvcmtlcnMnIHRvIHRoZSBudW1iZXIgb2YgcGFyYWxsZWwgd29y a2VycyB0aGF0IGFjdHVhbGx5IGNhbiBiZQotICogbGF1bmNoZWQgYW5kIHJlc2VydmVzIHRoZXNl IHdvcmtlcnMgKGlmIGFueSkgaW4gZ2xvYmFsIGF1dG92YWN1dW0gc3RhdGUuCi0gKgotICogTk9U RTogV2Ugd2lsbCB0cnkgdG8gcHJvdmlkZSBhcyBtYW55IHdvcmtlcnMgYXMgcmVxdWVzdGVkLCBl dmVuIGlmIGNhbGxlcgotICogd2lsbCBvY2N1cHkgYWxsIGF2YWlsYWJsZSB3b3JrZXJzLgorICog bndvcmtlcnMgaXMgYW4gaW4vb3V0IHBhcmFtZXRlcjsgdGhlIHJlcXVlc3RlZCBudW1iZXIgb2Yg cGFyYWxsZWwgd29ya2VycworICogdG8gcmVzZXJ2ZSBieSB0aGUgY2FsbGVyLCBhbmQgc2V0IHRv IHRoZSBhY3R1YWwgbnVtYmVyIG9mIHJlc2VydmVkIHdvcmtlcnMuCiAgKi8KIHZvaWQKIEF1dG9W YWN1dW1SZXNlcnZlUGFyYWxsZWxXb3JrZXJzKGludCAqbndvcmtlcnMpCiB7Ci0JLyogT25seSBs ZWFkZXIgd29ya2VyIGNhbiBjYWxsIHRoaXMgZnVuY3Rpb24uICovCisJLyogT25seSBsZWFkZXIg YXV0b3ZhY3V1bSB3b3JrZXIgY2FuIGNhbGwgdGhpcyBmdW5jdGlvbi4gKi8KIAlBc3NlcnQoQW1B dXRvVmFjdXVtV29ya2VyUHJvY2VzcygpICYmICFJc1BhcmFsbGVsV29ya2VyKCkpOwogCi0JLyoK LQkgKiBXZSBjYW4gb25seSByZXNlcnZlIHdvcmtlcnMgYXQgdGhlIGJlZ2lubmluZyBvZiBwYXJh bGxlbCBpbmRleAotCSAqIHByb2Nlc3NpbmcsIHNvIHdlIG11c3Qgbm90IGhhdmUgYW55IHJlc2Vy dmVkIHdvcmtlcnMgcmlnaHQgbm93LgotCSAqLworCS8qIFRoZSB3b3JrZXIgbXVzdCBub3QgaGF2 ZSBhbnkgcmVzZXJ2ZWQgd29ya2VycyB5ZXQgKi8KIAlBc3NlcnQoYXZfbndvcmtlcnNfcmVzZXJ2 ZWQgPT0gMCk7CiAKIAlMV0xvY2tBY3F1aXJlKEF1dG92YWN1dW1Mb2NrLCBMV19FWENMVVNJVkUp OwogCiAJLyogUHJvdmlkZSBhcyBtYW55IHdvcmtlcnMgYXMgd2UgY2FuLiAqLwotCSpud29ya2Vy cz0gTWluKEF1dG9WYWN1dW1TaG1lbS0+YXZfZnJlZVBhcmFsbGVsV29ya2VycywgKm53b3JrZXJz KTsKKwkqbndvcmtlcnMgPSBNaW4oQXV0b1ZhY3V1bVNobWVtLT5hdl9mcmVlUGFyYWxsZWxXb3Jr ZXJzLCAqbndvcmtlcnMpOwogCUF1dG9WYWN1dW1TaG1lbS0+YXZfZnJlZVBhcmFsbGVsV29ya2Vy cyAtPSAqbndvcmtlcnM7CiAKIAkvKiBSZW1lbWJlciBob3cgbWFueSB3b3JrZXJzIHdlIGhhdmUg cmVzZXJ2ZWQuICovCkBAIC0zNjMyLDggKzM2MjQsOCBAQCBjaGVja19hdl93b3JrZXJfZ3Vjcyh2 b2lkKQogfQogCiAvKgotICogTWFrZSBzdXJlIHRoYXQgbnVtYmVyIG9mIGZyZWUgcGFyYWxsZWwg d29ya2VycyBjb3JyZXNwb25kcyB0byB0aGUKLSAqIGF1dG92YWN1dW1fbWF4X3BhcmFsbGVsX3dv cmtlcnMgcGFyYW1ldGVyIChhZnRlciBpdCB3YXMgY2hhbmdlZCkuCisgKiBBZGp1c3RzIHRoZSBu dW1iZXIgb2YgZnJlZSBwYXJhbGxlbCB3b3JrZXJzIGNvcnJlc3BvbmRzIHRvIHRoZSBuZXcKKyAq IGF1dG92YWN1dW1fbWF4X3BhcmFsbGVsX3dvcmtlcnMgdmFsdWUuCiAgKi8KIHN0YXRpYyB2b2lk CiBhZGp1c3RfZnJlZV9wYXJhbGxlbF93b3JrZXJzKGludCBwcmV2X21heF9wYXJhbGxlbF93b3Jr ZXJzKQo= --000000000000bed4e0064863c694--