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 1kjxnT-000492-9w for pgsql-hackers@arkaria.postgresql.org; Tue, 01 Dec 2020 05:01:51 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1kjxnR-000176-K9 for pgsql-hackers@arkaria.postgresql.org; Tue, 01 Dec 2020 05:01:49 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kjxnR-00016y-4x for pgsql-hackers@lists.postgresql.org; Tue, 01 Dec 2020 05:01:49 +0000 Received: from oss.nttdata.com ([49.212.34.109]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kjxnN-0002GT-1G for pgsql-hackers@postgresql.org; Tue, 01 Dec 2020 05:01:47 +0000 Received: from hnk.local (p1295030-ipngn4902funabasi.chiba.ocn.ne.jp [153.166.85.30]) by oss.nttdata.com (Postfix) with ESMTPSA id AF741622EA; Tue, 1 Dec 2020 14:01:41 +0900 (JST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.102.3 at oss.nttdata.com Subject: Re: Add statistics to pg_stat_wal view for wal related parameter tuning To: Masahiro Ikeda Cc: pgsql-hackers References: <35ef960128b90bfae3b3fdf60a3a860f@oss.nttdata.com> <11e81f0b7d90dd69077d3d964a9a4da9@oss.nttdata.com> <79620b5c-ecf1-3d4f-80b5-7e311b7a0662@oss.nttdata.com> <89de5056627ebdd144967959bd789bd6@oss.nttdata.com> <58ccc451-8429-ce44-f0b7-773c8dfedf45@oss.nttdata.com> <7eb4ebd487b53200bde98ba2f0a7e789@oss.nttdata.com> From: Fujii Masao Message-ID: Date: Tue, 1 Dec 2020 14:01:41 +0900 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: <7eb4ebd487b53200bde98ba2f0a7e789@oss.nttdata.com> Content-Type: multipart/mixed; boundary="------------4AC1E74C5317C7733C2306CF" Content-Language: en-US List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk This is a multi-part message in MIME format. --------------4AC1E74C5317C7733C2306CF Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 2020/11/26 16:07, Masahiro Ikeda wrote: > On 2020-11-25 20:19, Fujii Masao wrote: >> On 2020/11/19 16:31, Masahiro Ikeda wrote: >>> On 2020-11-17 11:46, Fujii Masao wrote: >>>> On 2020/11/16 16:35, Masahiro Ikeda wrote: >>>>> On 2020-11-12 14:58, Fujii Masao wrote: >>>>>> On 2020/11/06 10:25, Masahiro Ikeda wrote: >>>>>>> On 2020-10-30 11:50, Fujii Masao wrote: >>>>>>>> On 2020/10/29 17:03, Masahiro Ikeda wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> Thanks for your comments and advice. I updated the patch. >>>>>>>>> >>>>>>>>> On 2020-10-21 18:03, Kyotaro Horiguchi wrote: >>>>>>>>>> At Tue, 20 Oct 2020 16:11:29 +0900, Masahiro Ikeda >>>>>>>>>> wrote in >>>>>>>>>>> On 2020-10-20 12:46, Amit Kapila wrote: >>>>>>>>>>> > I see that we also need to add extra code to capture these stats (some >>>>>>>>>>> > of which is in performance-critical path especially in >>>>>>>>>>> > XLogInsertRecord) which again makes me a bit uncomfortable. It might >>>>>>>>>>> > be that it is all fine as it is very important to collect these stats >>>>>>>>>>> > at cluster-level in spite that the same information can be gathered at >>>>>>>>>>> > statement-level to help customers but I don't see a very strong case >>>>>>>>>>> > for that in your proposal. >>>>>>>>>> >>>>>>>>>> We should avoid that duplication as possible even if the both number >>>>>>>>>> are important. >>>>>>>>>> >>>>>>>>>>> Also about performance, I thought there are few impacts because it >>>>>>>>>>> increments stats in memory. If I can implement to reuse pgWalUsage's >>>>>>>>>>> value which already collects these stats, there is no impact in >>>>>>>>>>> XLogInsertRecord. >>>>>>>>>>> For example, how about pg_stat_wal() calculates the accumulated >>>>>>>>>>> value of wal_records, wal_fpi, and wal_bytes to use pgWalUsage's >>>>>>>>>>> value? >>>>>>>>>> >>>>>>>>>> I don't think that works, but it would work that pgstat_send_wal() >>>>>>>>>> takes the difference of that values between two successive calls. >>>>>>>>>> >>>>>>>>>> WalUsage prevWalUsage; >>>>>>>>>> ... >>>>>>>>>> pgstat_send_wal() >>>>>>>>>> { >>>>>>>>>> .. >>>>>>>>>>    /* fill in some values using pgWalUsage */ >>>>>>>>>>    WalStats.m_wal_bytes   = pgWalUsage.wal_bytes   - prevWalUsage.wal_bytes; >>>>>>>>>>    WalStats.m_wal_records = pgWalUsage.wal_records - prevWalUsage.wal_records; >>>>>>>>>>    WalStats.m_wal_wal_fpi = pgWalUsage.wal_fpi     - prevWalUsage.wal_fpi; >>>>>>>>>> ... >>>>>>>>>>    pgstat_send(&WalStats, sizeof(WalStats)); >>>>>>>>>> >>>>>>>>>>    /* remember the current numbers */ >>>>>>>>>>    prevWalUsage = pgWalUsage; >>>>>>>>> >>>>>>>>> Thanks for Horiguchi-san's advice, I changed to reuse pgWalUsage >>>>>>>>> which is already defined and eliminates the extra overhead. >>>>>>>> >>>>>>>> +    /* fill in some values using pgWalUsage */ >>>>>>>> +    WalStats.m_wal_bytes = pgWalUsage.wal_bytes - prevWalUsage.wal_bytes; >>>>>>>> +    WalStats.m_wal_records = pgWalUsage.wal_records - prevWalUsage.wal_records; >>>>>>>> +    WalStats.m_wal_fpi = pgWalUsage.wal_fpi - prevWalUsage.wal_fpi; >>>>>>>> >>>>>>>> It's better to use WalUsageAccumDiff() here? >>>>>>> >>>>>>> Yes, thanks. I fixed it. >>>>>>> >>>>>>>> prevWalUsage needs to be initialized with pgWalUsage? >>>>>>>> >>>>>>>> +                if (AmWalWriterProcess()){ >>>>>>>> +                    WalStats.m_wal_write_walwriter++; >>>>>>>> +                } >>>>>>>> +                else >>>>>>>> +                { >>>>>>>> +                    WalStats.m_wal_write_backend++; >>>>>>>> +                } >>>>>>>> >>>>>>>> I think that it's better not to separate m_wal_write_xxx into two for >>>>>>>> walwriter and other processes. Instead, we can use one m_wal_write_xxx >>>>>>>> counter and make pgstat_send_wal() send also the process type to >>>>>>>> the stats collector. Then the stats collector can accumulate the counters >>>>>>>> per process type if necessary. If we adopt this approach, we can easily >>>>>>>> extend pg_stat_wal so that any fields can be reported per process type. >>>>>>> >>>>>>> I'll remove the above source code because these counters are not useful. >>>>>>> >>>>>>> >>>>>>> On 2020-10-30 12:00, Fujii Masao wrote: >>>>>>>> On 2020/10/20 11:31, Masahiro Ikeda wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> I think we need to add some statistics to pg_stat_wal view. >>>>>>>>> >>>>>>>>> Although there are some parameter related WAL, >>>>>>>>> there are few statistics for tuning them. >>>>>>>>> >>>>>>>>> I think it's better to provide the following statistics. >>>>>>>>> Please let me know your comments. >>>>>>>>> >>>>>>>>> ``` >>>>>>>>> postgres=# SELECT * from pg_stat_wal; >>>>>>>>> -[ RECORD 1 ]-------+------------------------------ >>>>>>>>> wal_records         | 2000224 >>>>>>>>> wal_fpi             | 47 >>>>>>>>> wal_bytes           | 248216337 >>>>>>>>> wal_buffers_full    | 20954 >>>>>>>>> wal_init_file       | 8 >>>>>>>>> wal_write_backend   | 20960 >>>>>>>>> wal_write_walwriter | 46 >>>>>>>>> wal_write_time      | 51 >>>>>>>>> wal_sync_backend    | 7 >>>>>>>>> wal_sync_walwriter  | 8 >>>>>>>>> wal_sync_time       | 0 >>>>>>>>> stats_reset         | 2020-10-20 11:04:51.307771+09 >>>>>>>>> ``` >>>>>>>>> >>>>>>>>> 1. Basic statistics of WAL activity >>>>>>>>> >>>>>>>>> - wal_records: Total number of WAL records generated >>>>>>>>> - wal_fpi: Total number of WAL full page images generated >>>>>>>>> - wal_bytes: Total amount of WAL bytes generated >>>>>>>>> >>>>>>>>> To understand DB's performance, first, we will check the performance >>>>>>>>> trends for the entire database instance. >>>>>>>>> For example, if the number of wal_fpi becomes higher, users may tune >>>>>>>>> "wal_compression", "checkpoint_timeout" and so on. >>>>>>>>> >>>>>>>>> Although users can check the above statistics via EXPLAIN, auto_explain, >>>>>>>>> autovacuum and pg_stat_statements now, >>>>>>>>> if users want to see the performance trends  for the entire database, >>>>>>>>> they must recalculate the statistics. >>>>>>>>> >>>>>>>>> I think it is useful to add the sum of the basic statistics. >>>>>>>>> >>>>>>>>> >>>>>>>>> 2.  WAL segment file creation >>>>>>>>> >>>>>>>>> - wal_init_file: Total number of WAL segment files created. >>>>>>>>> >>>>>>>>> To create a new WAL file may have an impact on the performance of >>>>>>>>> a write-heavy workload generating lots of WAL. If this number is reported high, >>>>>>>>> to reduce the number of this initialization, we can tune WAL-related parameters >>>>>>>>> so that more "recycled" WAL files can be held. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> 3. Number of when WAL is flushed >>>>>>>>> >>>>>>>>> - wal_write_backend : Total number of WAL data written to the disk by backends >>>>>>>>> - wal_write_walwriter : Total number of WAL data written to the disk by walwriter >>>>>>>>> - wal_sync_backend : Total number of WAL data synced to the disk by backends >>>>>>>>> - wal_sync_walwriter : Total number of WAL data synced to the disk by walwrite >>>>>>>>> >>>>>>>>> I think it's useful for tuning "synchronous_commit" and "commit_delay" for query executions. >>>>>>>>> If the number of WAL is flushed is high, users can know "synchronous_commit" is useful for the workload. >>>>>>>> >>>>>>>> I just wonder how useful these counters are. Even without these counters, >>>>>>>> we already know synchronous_commit=off is likely to cause the better >>>>>>>> performance (but has the risk of data loss). So ISTM that these counters are >>>>>>>> not so useful when tuning synchronous_commit. >>>>>>> >>>>>>> Thanks, my understanding was wrong. >>>>>>> I agreed that your comments. >>>>>>> >>>>>>> I merged the statistics of *_backend and *_walwriter. >>>>>>> I think the sum of them is useful to calculate the average per write/sync time. >>>>>>> For example, per write time is equals wal_write_time / wal_write. >>>>>> >>>>>> Understood. >>>>>> >>>>>> Thanks for updating the patch! >>>>> >>>>> Thanks for your comments. >>>>> >>>>>> patching file src/include/catalog/pg_proc.dat >>>>>> Hunk #1 FAILED at 5491. >>>>>> 1 out of 1 hunk FAILED -- saving rejects to file >>>>>> src/include/catalog/pg_proc.dat.rej >>>>>> >>>>>> I got this failure when applying the patch. Could you update the patch? >>>>> >>>>> Thanks, I updated the patch. >>>>> >>>>>> -       Number of times WAL data was written to the disk because WAL >>>>>> buffers got full >>>>>> +       Total number of times WAL data written to the disk because WAL >>>>>> buffers got full >>>>>> >>>>>> Isn't "was" necessary between "data" and "written"? >>>>> >>>>> Yes, I fixed it. >>>>> >>>>>> +      >>>>>> +       wal_bytes bigint >>>>>> >>>>>> Shouldn't the type of wal_bytes be numeric because the total number of >>>>>> WAL bytes can exceed the range of bigint? I think that the type of >>>>>> pg_stat_statements.wal_bytes is also numeric for the same reason. >>>>> >>>>> Thanks, I fixed it. >>>>> >>>>> Since I cast the type of wal_bytes from PgStat_Counter to uint64, >>>>> I changed the type of PgStat_MsgWal and PgStat_WalStats too. >>>>> >>>>>> +      >>>>>> +       wal_write_time bigint >>>>>> >>>>>> Shouldn't the type of wal_xxx_time be double precision, >>>>>> like pg_stat_database.blk_write_time? >>>>> >>>>> Thanks, I changed it. >>>>> >>>>>> Even when fsync is set to off or wal_sync_method is set to open_sync, >>>>>> wal_sync is incremented. Isn't this behavior confusing? >>>> >>>> What do you think about this comment? >>> >>> Sorry, I'll change to increment wal_sync and wal_sync_time only >>> if a specific fsync method is called. >>> >>>> I found that we discussed track-WAL-IO-timing feature at the past discussion >>>> about the similar feature [1]. But the feature was droppped from the proposal >>>> patch because there was the performance concern. So probably we need to >>>> revisit the past discussion and benchmark the performance. Thought? >>>> >>>> If track-WAL-IO-timing feature may cause performance regression, >>>> it might be an idea to extract wal_records, wal_fpi and wal_bytes parts >>>> from the patch and commit it at first. >>>> >>>> [1] >>>> https://postgr.es/m/CAJrrPGc6APFUGYNcPe4qcNxpL8gXKYv1KST+vwJcFtCSCEySnA@mail.gmail.com >>> >>> Thanks, I'll check the thread. >>> I agree to add basic statistics at first and I attached the patch. >> >> Thanks! >> >> +        /* Send WAL statistics */ >> +        pgstat_send_wal(); >> >> This is not necessary because walwriter generates no WAL data? > > No, it's not necessary. > Thanks. I fixed it. Thanks for updating the patch! I applied cosmetic changes to it. For example, I added more comments. Patch attached. Barring no objection, I will commit this patch. Regards, -- Fujii Masao Advanced Computing Technology Center Research and Development Headquarters NTT DATA CORPORATION --------------4AC1E74C5317C7733C2306CF Content-Type: text/plain; charset=UTF-8; x-mac-type="0"; x-mac-creator="0"; name="0002_add_basic_statistics_to_pg_stat_wal_view_fujii.patch" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename*0="0002_add_basic_statistics_to_pg_stat_wal_view_fujii.patch" ZGlmZiAtLWdpdCBhL2RvYy9zcmMvc2dtbC9tb25pdG9yaW5nLnNnbWwgYi9kb2Mvc3JjL3Nn bWwvbW9uaXRvcmluZy5zZ21sCmluZGV4IDk4ZTE5OTU0NTMuLjZlNjYxZDZmYWUgMTAwNjQ0 Ci0tLSBhL2RvYy9zcmMvc2dtbC9tb25pdG9yaW5nLnNnbWwKKysrIGIvZG9jL3NyYy9zZ21s L21vbml0b3Jpbmcuc2dtbApAQCAtMzQ0Nyw2ICszNDQ3LDMzIEBAIFNFTEVDVCBwaWQsIHdh aXRfZXZlbnRfdHlwZSwgd2FpdF9ldmVudCBGUk9NIHBnX3N0YXRfYWN0aXZpdHkgV0hFUkUg d2FpdF9ldmVudCBpCiAgICAgPC90aGVhZD4KIAogICAgIDx0Ym9keT4KKyAgICAgPHJvdz4K KyAgICAgIDxlbnRyeSByb2xlPSJjYXRhbG9nX3RhYmxlX2VudHJ5Ij48cGFyYSByb2xlPSJj b2x1bW5fZGVmaW5pdGlvbiI+CisgICAgICAgPHN0cnVjdGZpZWxkPndhbF9yZWNvcmRzPC9z dHJ1Y3RmaWVsZD4gPHR5cGU+YmlnaW50PC90eXBlPgorICAgICAgPC9wYXJhPgorICAgICAg PHBhcmE+CisgICAgICAgVG90YWwgbnVtYmVyIG9mIFdBTCByZWNvcmRzIGdlbmVyYXRlZAor ICAgICAgPC9wYXJhPjwvZW50cnk+CisgICAgIDwvcm93PgorCisgICAgIDxyb3c+CisgICAg ICA8ZW50cnkgcm9sZT0iY2F0YWxvZ190YWJsZV9lbnRyeSI+PHBhcmEgcm9sZT0iY29sdW1u X2RlZmluaXRpb24iPgorICAgICAgIDxzdHJ1Y3RmaWVsZD53YWxfZnBpPC9zdHJ1Y3RmaWVs ZD4gPHR5cGU+YmlnaW50PC90eXBlPgorICAgICAgPC9wYXJhPgorICAgICAgPHBhcmE+Cisg ICAgICAgVG90YWwgbnVtYmVyIG9mIFdBTCBmdWxsIHBhZ2UgaW1hZ2VzIGdlbmVyYXRlZAor ICAgICAgPC9wYXJhPjwvZW50cnk+CisgICAgIDwvcm93PgorCisgICAgIDxyb3c+CisgICAg ICA8ZW50cnkgcm9sZT0iY2F0YWxvZ190YWJsZV9lbnRyeSI+PHBhcmEgcm9sZT0iY29sdW1u X2RlZmluaXRpb24iPgorICAgICAgIDxzdHJ1Y3RmaWVsZD53YWxfYnl0ZXM8L3N0cnVjdGZp ZWxkPiA8dHlwZT5udW1lcmljPC90eXBlPgorICAgICAgPC9wYXJhPgorICAgICAgPHBhcmE+ CisgICAgICAgVG90YWwgYW1vdW50IG9mIFdBTCBieXRlcyBnZW5lcmF0ZWQKKyAgICAgIDwv cGFyYT48L2VudHJ5PgorICAgICA8L3Jvdz4KKwogICAgICA8cm93PgogICAgICAgPGVudHJ5 IHJvbGU9ImNhdGFsb2dfdGFibGVfZW50cnkiPjxwYXJhIHJvbGU9ImNvbHVtbl9kZWZpbml0 aW9uIj4KICAgICAgICA8c3RydWN0ZmllbGQ+d2FsX2J1ZmZlcnNfZnVsbDwvc3RydWN0Zmll bGQ+IDx0eXBlPmJpZ2ludDwvdHlwZT4KZGlmZiAtLWdpdCBhL3NyYy9iYWNrZW5kL2NhdGFs b2cvc3lzdGVtX3ZpZXdzLnNxbCBiL3NyYy9iYWNrZW5kL2NhdGFsb2cvc3lzdGVtX3ZpZXdz LnNxbAppbmRleCAyZTRhYTFjNGI2Li5iMTQwYzIxMGJjIDEwMDY0NAotLS0gYS9zcmMvYmFj a2VuZC9jYXRhbG9nL3N5c3RlbV92aWV3cy5zcWwKKysrIGIvc3JjL2JhY2tlbmQvY2F0YWxv Zy9zeXN0ZW1fdmlld3Muc3FsCkBAIC05OTMsNiArOTkzLDkgQEAgQ1JFQVRFIFZJRVcgcGdf c3RhdF9iZ3dyaXRlciBBUwogCiBDUkVBVEUgVklFVyBwZ19zdGF0X3dhbCBBUwogICAgIFNF TEVDVAorICAgICAgICB3LndhbF9yZWNvcmRzLAorICAgICAgICB3LndhbF9mcGksCisgICAg ICAgIHcud2FsX2J5dGVzLAogICAgICAgICB3LndhbF9idWZmZXJzX2Z1bGwsCiAgICAgICAg IHcuc3RhdHNfcmVzZXQKICAgICBGUk9NIHBnX3N0YXRfZ2V0X3dhbCgpIHc7CmRpZmYgLS1n aXQgYS9zcmMvYmFja2VuZC9wb3N0bWFzdGVyL3Bnc3RhdC5jIGIvc3JjL2JhY2tlbmQvcG9z dG1hc3Rlci9wZ3N0YXQuYwppbmRleCBlNzZlNjI3YzZiLi45YmFkMTQ5ODFiIDEwMDY0NAot LS0gYS9zcmMvYmFja2VuZC9wb3N0bWFzdGVyL3Bnc3RhdC5jCisrKyBiL3NyYy9iYWNrZW5k L3Bvc3RtYXN0ZXIvcGdzdGF0LmMKQEAgLTQxLDYgKzQxLDcgQEAKICNpbmNsdWRlICJjYXRh bG9nL3BnX2RhdGFiYXNlLmgiCiAjaW5jbHVkZSAiY2F0YWxvZy9wZ19wcm9jLmgiCiAjaW5j bHVkZSAiY29tbW9uL2lwLmgiCisjaW5jbHVkZSAiZXhlY3V0b3IvaW5zdHJ1bWVudC5oIgog I2luY2x1ZGUgImxpYnBxL2xpYnBxLmgiCiAjaW5jbHVkZSAibGlicHEvcHFzaWduYWwuaCIK ICNpbmNsdWRlICJtYi9wZ193Y2hhci5oIgpAQCAtMTQzLDYgKzE0NCwxNCBAQCBjaGFyCSAg ICpwZ3N0YXRfc3RhdF90bXBuYW1lID0gTlVMTDsKIFBnU3RhdF9Nc2dCZ1dyaXRlciBCZ1dy aXRlclN0YXRzOwogUGdTdGF0X01zZ1dhbCBXYWxTdGF0czsKIAorLyoKKyAqIFdBTCB1c2Fn ZSBjb3VudGVycyBzYXZlZCBmcm9tIHBnV0FMVXNhZ2UgYXQgdGhlIHByZXZpb3VzIGNhbGwg dG8KKyAqIHBnc3RhdF9zZW5kX3dhbCgpLiBUaGlzIGlzIHVzZWQgdG8gY2FsY3VsYXRlIGhv dyBtdWNoIFdBTCB1c2FnZQorICogaGFwcGVucyBiZXR3ZWVuIHBnc3RhdF9zZW5kX3dhbCgp IGNhbGxzLCBieSBzdWJzdHJhY3RpbmcKKyAqIHRoZSBwcmV2aW91cyBjb3VudGVycyBmcm9t IHRoZSBjdXJyZW50IG9uZXMuCisgKi8KK3N0YXRpYyBXYWxVc2FnZSBwcmV2V2FsVXNhZ2U7 CisKIC8qCiAgKiBMaXN0IG9mIFNMUlUgbmFtZXMgdGhhdCB3ZSBrZWVwIHN0YXRzIGZvci4g IFRoZXJlIGlzIG5vIGNlbnRyYWwgcmVnaXN0cnkgb2YKICAqIFNMUlVzLCBzbyB3ZSB1c2Ug dGhpcyBmaXhlZCBsaXN0IGluc3RlYWQuICBUaGUgIm90aGVyIiBlbnRyeSBpcyB1c2VkIGZv cgpAQCAtMzA0OCw2ICszMDU3LDEzIEBAIHBnc3RhdF9pbml0aWFsaXplKHZvaWQpCiAJCU15 QkVFbnRyeSA9ICZCYWNrZW5kU3RhdHVzQXJyYXlbTWF4QmFja2VuZHMgKyBNeUF1eFByb2NU eXBlXTsKIAl9CiAKKwkvKgorCSAqIEluaXRpYWxpemUgcHJldldhbFVzYWdlIHdpdGggcGdX YWxVc2FnZSBzbyB0aGF0IHBnc3RhdF9zZW5kX3dhbCgpIGNhbgorCSAqIGNhbGN1bGF0ZSBo b3cgbXVjaCBwZ1dhbFVzYWdlIGNvdW50ZXJzIGFyZSBpbmNyZWFzZWQgYnkgc3Vic3RyYWN0 aW5nCisJICogcHJldldhbFVzYWdlIGZyb20gcGdXYWxVc2FnZS4KKwkgKi8KKwlwcmV2V2Fs VXNhZ2UgPSBwZ1dhbFVzYWdlOworCiAJLyogU2V0IHVwIGEgcHJvY2Vzcy1leGl0IGhvb2sg dG8gY2xlYW4gdXAgKi8KIAlvbl9zaG1lbV9leGl0KHBnc3RhdF9iZXNodXRkb3duX2hvb2ss IDApOwogfQpAQCAtNDU3Nyw2ICs0NTkzLDIwIEBAIHBnc3RhdF9zZW5kX3dhbCh2b2lkKQog CS8qIFdlIGFzc3VtZSB0aGlzIGluaXRpYWxpemVzIHRvIHplcm9lcyAqLwogCXN0YXRpYyBj b25zdCBQZ1N0YXRfTXNnV2FsIGFsbF96ZXJvZXM7CiAKKwlXYWxVc2FnZQl3YWx1c2FnZTsK KworCS8qCisJICogQ2FsY3VsYXRlIGhvdyBtdWNoIFdBTCB1c2FnZSBjb3VudGVycyBhcmUg aW5jcmVhc2VkIGJ5IHN1YnN0cmFjdGluZyB0aGUKKwkgKiBwcmV2aW91cyBjb3VudGVycyBm cm9tIHRoZSBjdXJyZW50IG9uZXMuIEZpbGwgdGhlIHJlc3VsdHMgaW4gV0FMIHN0YXRzCisJ ICogbWVzc2FnZS4KKwkgKi8KKwlNZW1TZXQoJndhbHVzYWdlLCAwLCBzaXplb2YoV2FsVXNh Z2UpKTsKKwlXYWxVc2FnZUFjY3VtRGlmZigmd2FsdXNhZ2UsICZwZ1dhbFVzYWdlLCAmcHJl dldhbFVzYWdlKTsKKworCVdhbFN0YXRzLm1fd2FsX3JlY29yZHMgPSB3YWx1c2FnZS53YWxf cmVjb3JkczsKKwlXYWxTdGF0cy5tX3dhbF9mcGkgPSB3YWx1c2FnZS53YWxfZnBpOworCVdh bFN0YXRzLm1fd2FsX2J5dGVzID0gd2FsdXNhZ2Uud2FsX2J5dGVzOworCiAJLyoKIAkgKiBU aGlzIGZ1bmN0aW9uIGNhbiBiZSBjYWxsZWQgZXZlbiBpZiBub3RoaW5nIGF0IGFsbCBoYXMg aGFwcGVuZWQuIEluCiAJICogdGhpcyBjYXNlLCBhdm9pZCBzZW5kaW5nIGEgY29tcGxldGVs eSBlbXB0eSBtZXNzYWdlIHRvIHRoZSBzdGF0cwpAQCAtNDU5MSw2ICs0NjIxLDExIEBAIHBn c3RhdF9zZW5kX3dhbCh2b2lkKQogCXBnc3RhdF9zZXRoZWFkZXIoJldhbFN0YXRzLm1faGRy LCBQR1NUQVRfTVRZUEVfV0FMKTsKIAlwZ3N0YXRfc2VuZCgmV2FsU3RhdHMsIHNpemVvZihX YWxTdGF0cykpOwogCisJLyoKKwkgKiBTYXZlIHRoZSBjdXJyZW50IGNvdW50ZXJzIGZvciB0 aGUgc3Vic2VxdWVudCBjYWxjdWxhdGlvbiBvZiBXQUwgdXNhZ2UuCisJICovCisJcHJldldh bFVzYWdlID0gcGdXYWxVc2FnZTsKKwogCS8qCiAJICogQ2xlYXIgb3V0IHRoZSBzdGF0aXN0 aWNzIGJ1ZmZlciwgc28gaXQgY2FuIGJlIHJlLXVzZWQuCiAJICovCkBAIC02NzU5LDYgKzY3 OTQsOSBAQCBwZ3N0YXRfcmVjdl9iZ3dyaXRlcihQZ1N0YXRfTXNnQmdXcml0ZXIgKm1zZywg aW50IGxlbikKIHN0YXRpYyB2b2lkCiBwZ3N0YXRfcmVjdl93YWwoUGdTdGF0X01zZ1dhbCAq bXNnLCBpbnQgbGVuKQogeworCXdhbFN0YXRzLndhbF9yZWNvcmRzICs9IG1zZy0+bV93YWxf cmVjb3JkczsKKwl3YWxTdGF0cy53YWxfZnBpICs9IG1zZy0+bV93YWxfZnBpOworCXdhbFN0 YXRzLndhbF9ieXRlcyArPSBtc2ctPm1fd2FsX2J5dGVzOwogCXdhbFN0YXRzLndhbF9idWZm ZXJzX2Z1bGwgKz0gbXNnLT5tX3dhbF9idWZmZXJzX2Z1bGw7CiB9CiAKZGlmZiAtLWdpdCBh L3NyYy9iYWNrZW5kL3V0aWxzL2FkdC9wZ3N0YXRmdW5jcy5jIGIvc3JjL2JhY2tlbmQvdXRp bHMvYWR0L3Bnc3RhdGZ1bmNzLmMKaW5kZXggYTIxMGZjOTNiNC4uNmFmZTFiNmY1NiAxMDA2 NDQKLS0tIGEvc3JjL2JhY2tlbmQvdXRpbHMvYWR0L3Bnc3RhdGZ1bmNzLmMKKysrIGIvc3Jj L2JhY2tlbmQvdXRpbHMvYWR0L3Bnc3RhdGZ1bmNzLmMKQEAgLTE3MDMsMTAgKzE3MDMsMTEg QEAgcGdfc3RhdF9nZXRfYnVmX2FsbG9jKFBHX0ZVTkNUSU9OX0FSR1MpCiBEYXR1bQogcGdf c3RhdF9nZXRfd2FsKFBHX0ZVTkNUSU9OX0FSR1MpCiB7Ci0jZGVmaW5lIFBHX1NUQVRfR0VU X1dBTF9DT0xTCTIKKyNkZWZpbmUgUEdfU1RBVF9HRVRfV0FMX0NPTFMJNQogCVR1cGxlRGVz Ywl0dXBkZXNjOwogCURhdHVtCQl2YWx1ZXNbUEdfU1RBVF9HRVRfV0FMX0NPTFNdOwogCWJv b2wJCW51bGxzW1BHX1NUQVRfR0VUX1dBTF9DT0xTXTsKKwljaGFyCQlidWZbMjU2XTsKIAlQ Z1N0YXRfV2FsU3RhdHMgKndhbF9zdGF0czsKIAogCS8qIEluaXRpYWxpc2UgdmFsdWVzIGFu ZCBOVUxMIGZsYWdzIGFycmF5cyAqLwpAQCAtMTcxNSw5ICsxNzE2LDE1IEBAIHBnX3N0YXRf Z2V0X3dhbChQR19GVU5DVElPTl9BUkdTKQogCiAJLyogSW5pdGlhbGlzZSBhdHRyaWJ1dGVz IGluZm9ybWF0aW9uIGluIHRoZSB0dXBsZSBkZXNjcmlwdG9yICovCiAJdHVwZGVzYyA9IENy ZWF0ZVRlbXBsYXRlVHVwbGVEZXNjKFBHX1NUQVRfR0VUX1dBTF9DT0xTKTsKLQlUdXBsZURl c2NJbml0RW50cnkodHVwZGVzYywgKEF0dHJOdW1iZXIpIDEsICJ3YWxfYnVmZmVyc19mdWxs IiwKKwlUdXBsZURlc2NJbml0RW50cnkodHVwZGVzYywgKEF0dHJOdW1iZXIpIDEsICJ3YWxf cmVjb3JkcyIsCiAJCQkJCSAgIElOVDhPSUQsIC0xLCAwKTsKLQlUdXBsZURlc2NJbml0RW50 cnkodHVwZGVzYywgKEF0dHJOdW1iZXIpIDIsICJzdGF0c19yZXNldCIsCisJVHVwbGVEZXNj SW5pdEVudHJ5KHR1cGRlc2MsIChBdHRyTnVtYmVyKSAyLCAid2FsX2ZwaSIsCisJCQkJCSAg IElOVDhPSUQsIC0xLCAwKTsKKwlUdXBsZURlc2NJbml0RW50cnkodHVwZGVzYywgKEF0dHJO dW1iZXIpIDMsICJ3YWxfYnl0ZXMiLAorCQkJCQkgICBOVU1FUklDT0lELCAtMSwgMCk7CisJ VHVwbGVEZXNjSW5pdEVudHJ5KHR1cGRlc2MsIChBdHRyTnVtYmVyKSA0LCAid2FsX2J1ZmZl cnNfZnVsbCIsCisJCQkJCSAgIElOVDhPSUQsIC0xLCAwKTsKKwlUdXBsZURlc2NJbml0RW50 cnkodHVwZGVzYywgKEF0dHJOdW1iZXIpIDUsICJzdGF0c19yZXNldCIsCiAJCQkJCSAgIFRJ TUVTVEFNUFRaT0lELCAtMSwgMCk7CiAKIAlCbGVzc1R1cGxlRGVzYyh0dXBkZXNjKTsKQEAg LTE3MjYsOCArMTczMywxOCBAQCBwZ19zdGF0X2dldF93YWwoUEdfRlVOQ1RJT05fQVJHUykK IAl3YWxfc3RhdHMgPSBwZ3N0YXRfZmV0Y2hfc3RhdF93YWwoKTsKIAogCS8qIEZpbGwgdmFs dWVzIGFuZCBOVUxMcyAqLwotCXZhbHVlc1swXSA9IEludDY0R2V0RGF0dW0od2FsX3N0YXRz LT53YWxfYnVmZmVyc19mdWxsKTsKLQl2YWx1ZXNbMV0gPSBUaW1lc3RhbXBUekdldERhdHVt KHdhbF9zdGF0cy0+c3RhdF9yZXNldF90aW1lc3RhbXApOworCXZhbHVlc1swXSA9IEludDY0 R2V0RGF0dW0od2FsX3N0YXRzLT53YWxfcmVjb3Jkcyk7CisJdmFsdWVzWzFdID0gSW50NjRH ZXREYXR1bSh3YWxfc3RhdHMtPndhbF9mcGkpOworCisJLyogQ29udmVydCB0byBudW1lcmlj LiAqLworCXNucHJpbnRmKGJ1Ziwgc2l6ZW9mIGJ1ZiwgVUlOVDY0X0ZPUk1BVCwgd2FsX3N0 YXRzLT53YWxfYnl0ZXMpOworCXZhbHVlc1syXSA9IERpcmVjdEZ1bmN0aW9uQ2FsbDMobnVt ZXJpY19pbiwKKwkJCQkJCQkJCUNTdHJpbmdHZXREYXR1bShidWYpLAorCQkJCQkJCQkJT2Jq ZWN0SWRHZXREYXR1bSgwKSwKKwkJCQkJCQkJCUludDMyR2V0RGF0dW0oLTEpKTsKKworCXZh bHVlc1szXSA9IEludDY0R2V0RGF0dW0od2FsX3N0YXRzLT53YWxfYnVmZmVyc19mdWxsKTsK Kwl2YWx1ZXNbNF0gPSBUaW1lc3RhbXBUekdldERhdHVtKHdhbF9zdGF0cy0+c3RhdF9yZXNl dF90aW1lc3RhbXApOwogCiAJLyogUmV0dXJucyB0aGUgcmVjb3JkIGFzIERhdHVtICovCiAJ UEdfUkVUVVJOX0RBVFVNKEhlYXBUdXBsZUdldERhdHVtKGhlYXBfZm9ybV90dXBsZSh0dXBk ZXNjLCB2YWx1ZXMsIG51bGxzKSkpOwpkaWZmIC0tZ2l0IGEvc3JjL2luY2x1ZGUvY2F0YWxv Zy9wZ19wcm9jLmRhdCBiL3NyYy9pbmNsdWRlL2NhdGFsb2cvcGdfcHJvYy5kYXQKaW5kZXgg ZTdmYmRhOWY4MS4uZmMyMjAyYjg0MyAxMDA2NDQKLS0tIGEvc3JjL2luY2x1ZGUvY2F0YWxv Zy9wZ19wcm9jLmRhdAorKysgYi9zcmMvaW5jbHVkZS9jYXRhbG9nL3BnX3Byb2MuZGF0CkBA IC01NTAwLDggKzU1MDAsOSBAQAogeyBvaWQgPT4gJzExMzYnLCBkZXNjciA9PiAnc3RhdGlz dGljczogaW5mb3JtYXRpb24gYWJvdXQgV0FMIGFjdGl2aXR5JywKICAgcHJvbmFtZSA9PiAn cGdfc3RhdF9nZXRfd2FsJywgcHJvaXNzdHJpY3QgPT4gJ2YnLCBwcm92b2xhdGlsZSA9PiAn cycsCiAgIHByb3BhcmFsbGVsID0+ICdyJywgcHJvcmV0dHlwZSA9PiAncmVjb3JkJywgcHJv YXJndHlwZXMgPT4gJycsCi0gIHByb2FsbGFyZ3R5cGVzID0+ICd7aW50OCx0aW1lc3RhbXB0 en0nLCBwcm9hcmdtb2RlcyA9PiAne28sb30nLAotICBwcm9hcmduYW1lcyA9PiAne3dhbF9i dWZmZXJzX2Z1bGwsc3RhdHNfcmVzZXR9JywKKyAgIHByb2FsbGFyZ3R5cGVzID0+ICd7aW50 OCxpbnQ4LG51bWVyaWMsaW50OCx0aW1lc3RhbXB0en0nLAorICAgcHJvYXJnbW9kZXMgPT4g J3tvLG8sbyxvLG99JywKKyAgIHByb2FyZ25hbWVzID0+ICd7d2FsX3JlY29yZHMsd2FsX2Zw aSx3YWxfYnl0ZXMsd2FsX2J1ZmZlcnNfZnVsbCxzdGF0c19yZXNldH0nLAogICBwcm9zcmMg PT4gJ3BnX3N0YXRfZ2V0X3dhbCcgfSwKIAogeyBvaWQgPT4gJzIzMDYnLCBkZXNjciA9PiAn c3RhdGlzdGljczogaW5mb3JtYXRpb24gYWJvdXQgU0xSVSBjYWNoZXMnLApkaWZmIC0tZ2l0 IGEvc3JjL2luY2x1ZGUvcGdzdGF0LmggYi9zcmMvaW5jbHVkZS9wZ3N0YXQuaAppbmRleCAy NTdlNTE1YmZlLi41OTU0MDY4ZGVjIDEwMDY0NAotLS0gYS9zcmMvaW5jbHVkZS9wZ3N0YXQu aAorKysgYi9zcmMvaW5jbHVkZS9wZ3N0YXQuaApAQCAtNDU5LDYgKzQ1OSw5IEBAIHR5cGVk ZWYgc3RydWN0IFBnU3RhdF9Nc2dCZ1dyaXRlcgogdHlwZWRlZiBzdHJ1Y3QgUGdTdGF0X01z Z1dhbAogewogCVBnU3RhdF9Nc2dIZHIgbV9oZHI7CisJUGdTdGF0X0NvdW50ZXIgbV93YWxf cmVjb3JkczsKKwlQZ1N0YXRfQ291bnRlciBtX3dhbF9mcGk7CisJdWludDY0CQltX3dhbF9i eXRlczsKIAlQZ1N0YXRfQ291bnRlciBtX3dhbF9idWZmZXJzX2Z1bGw7CiB9IFBnU3RhdF9N c2dXYWw7CiAKQEAgLTc5OCw2ICs4MDEsOSBAQCB0eXBlZGVmIHN0cnVjdCBQZ1N0YXRfR2xv YmFsU3RhdHMKICAqLwogdHlwZWRlZiBzdHJ1Y3QgUGdTdGF0X1dhbFN0YXRzCiB7CisJUGdT dGF0X0NvdW50ZXIgd2FsX3JlY29yZHM7CisJUGdTdGF0X0NvdW50ZXIgd2FsX2ZwaTsKKwl1 aW50NjQJCXdhbF9ieXRlczsKIAlQZ1N0YXRfQ291bnRlciB3YWxfYnVmZmVyc19mdWxsOwog CVRpbWVzdGFtcFR6IHN0YXRfcmVzZXRfdGltZXN0YW1wOwogfSBQZ1N0YXRfV2FsU3RhdHM7 CmRpZmYgLS1naXQgYS9zcmMvdGVzdC9yZWdyZXNzL2V4cGVjdGVkL3J1bGVzLm91dCBiL3Ny Yy90ZXN0L3JlZ3Jlc3MvZXhwZWN0ZWQvcnVsZXMub3V0CmluZGV4IDA5N2ZmNWQxMTEuLjYy OTNhYjU3YmMgMTAwNjQ0Ci0tLSBhL3NyYy90ZXN0L3JlZ3Jlc3MvZXhwZWN0ZWQvcnVsZXMu b3V0CisrKyBiL3NyYy90ZXN0L3JlZ3Jlc3MvZXhwZWN0ZWQvcnVsZXMub3V0CkBAIC0yMTM4 LDkgKzIxMzgsMTIgQEAgcGdfc3RhdF91c2VyX3RhYmxlc3wgU0VMRUNUIHBnX3N0YXRfYWxs X3RhYmxlcy5yZWxpZCwKICAgICBwZ19zdGF0X2FsbF90YWJsZXMuYXV0b2FuYWx5emVfY291 bnQKICAgIEZST00gcGdfc3RhdF9hbGxfdGFibGVzCiAgIFdIRVJFICgocGdfc3RhdF9hbGxf dGFibGVzLnNjaGVtYW5hbWUgPD4gQUxMIChBUlJBWVsncGdfY2F0YWxvZyc6Om5hbWUsICdp bmZvcm1hdGlvbl9zY2hlbWEnOjpuYW1lXSkpIEFORCAocGdfc3RhdF9hbGxfdGFibGVzLnNj aGVtYW5hbWUgIX4gJ15wZ190b2FzdCc6OnRleHQpKTsKLXBnX3N0YXRfd2FsfCBTRUxFQ1Qg dy53YWxfYnVmZmVyc19mdWxsLAorcGdfc3RhdF93YWx8IFNFTEVDVCB3LndhbF9yZWNvcmRz LAorICAgIHcud2FsX2ZwaSwKKyAgICB3LndhbF9ieXRlcywKKyAgICB3LndhbF9idWZmZXJz X2Z1bGwsCiAgICAgdy5zdGF0c19yZXNldAotICAgRlJPTSBwZ19zdGF0X2dldF93YWwoKSB3 KHdhbF9idWZmZXJzX2Z1bGwsIHN0YXRzX3Jlc2V0KTsKKyAgIEZST00gcGdfc3RhdF9nZXRf d2FsKCkgdyh3YWxfcmVjb3Jkcywgd2FsX2ZwaSwgd2FsX2J5dGVzLCB3YWxfYnVmZmVyc19m dWxsLCBzdGF0c19yZXNldCk7CiBwZ19zdGF0X3dhbF9yZWNlaXZlcnwgU0VMRUNUIHMucGlk LAogICAgIHMuc3RhdHVzLAogICAgIHMucmVjZWl2ZV9zdGFydF9sc24sCg== --------------4AC1E74C5317C7733C2306CF--