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 1udjYQ-00CKGt-1x for pgsql-performance@arkaria.postgresql.org; Mon, 21 Jul 2025 05:59:14 +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 1udjYO-00E7R8-N8 for pgsql-performance@arkaria.postgresql.org; Mon, 21 Jul 2025 05:59:12 +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 1udjYO-00E7R0-Al for pgsql-performance@lists.postgresql.org; Mon, 21 Jul 2025 05:59:12 +0000 Received: from mail-oo1-xc34.google.com ([2607:f8b0:4864:20::c34]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1udjYL-008uBU-32 for pgsql-performance@lists.postgresql.org; Mon, 21 Jul 2025 05:59:12 +0000 Received: by mail-oo1-xc34.google.com with SMTP id 006d021491bc7-615d75ee53dso191615eaf.0 for ; Sun, 20 Jul 2025 22:59:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1753077548; x=1753682348; 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=wDRuEOlox2BA3Ms5YO3t4S2ZefuIUWFY1fMcsYKuiVk=; b=UtR7mhGL37ftkB3fPooUiJ+QbG+G/w0nEql8qaLeOaWKQOI1AIgZxgS8pZEL2a+pWA LuXkJFKdeIsmLVOskbpMksTwEz25beQJoGvDg+iUpjLfNxVZuXJE9zOKxbDA92LGNnSc 7b3RRrgmwuNoctIe9odWBLmqbQaGS4iXPcXt2hUgTlbX79sGMWTheU1+R8aB5EvOkhOj TflPuwWlPzzRquupC6x/0n+KkPp82JjyALUEZaxANeJ8KY+J/WrbFhUT7hxZIuDSwo17 CpUSxBCmlv8L1kqbQfvH5DHisD9ejEJXWb/DRWxGc+PmrdZ32Nh19pJQWYzZBTNhORG5 e4wA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1753077548; x=1753682348; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=wDRuEOlox2BA3Ms5YO3t4S2ZefuIUWFY1fMcsYKuiVk=; b=MXNUJpIf+iAU7v/cW8LAGcqKvwWjK1ILE5YjPKokWmSrdoZV29+UvQz40a3AIeAK7Y 2uq6fSSPNKTHkx9OgXDiaiwFb21fJsp/7AHmEsMOmKTSD46nTX8akQ2TS9ykS6S5WHIf kWypFqNSZ+aOeLLEE3vzfts/Qxs1QLN56UhsrWhlWLAYOoXOiy632JeIADT4HnornEax ljkE/+++ZAUjdw1llPF+dPM7OW6lfSsjEpt6Ke17ygrTwqPqU6hjMpTQHBBtV/lDKrIK CNab5IWUINOxGKYSUiOEgDMlR3lvsdWPS1fDo/Ur9G2IYKsYxkn6omQZNlADNKKa9Fwc k2qQ== X-Forwarded-Encrypted: i=1; AJvYcCV6pKgqE3NMyMx7ujWea2xbx2fSmZJQiG0vbS6n+xoN6IxUbp++TAr9pNFd5KtfzbGTBDoeipUnyejenfxav/x/3w==@lists.postgresql.org X-Gm-Message-State: AOJu0Yx5K8HM/nmGUfvR3+qK24tTF+NZGBzV0oVwEW+6MI2/t3YXZNeG eyRwj7aTBw4UxHjsiGLQnFfqw3cDh+FniIT+kcoAHdLYUuLLMQ/6A6C3XDUlEGw+D/XNVidJGnc +gGFKYuXc4ydfUywVVoPZtrtB8VEUQKA= X-Gm-Gg: ASbGncv72eosxM815c5uAV7Kf1H5d+bW/3AvHW65kpJYuOgHKW38fFKJCCKjcAVjVLC S/zHa+EXHpyjy35nGfovvd7eFdzRnPM7vWGTWFEqRrqQvUUKmCW+RWvW+UknGaNBKA6/TejRv/m 5Nkb8pbjgK3pCnpOLtRRbxDh+lrfS8hFqPh8r8kU74Vdf/frA9IRvQ7tCMOfk7j8fNDixVIM1tL 8Fcfeul X-Google-Smtp-Source: AGHT+IFSCE1+R71Chqo0YWa1qIkopHEe1G8tJFr/dJj1ElNHwPv4sAP//wDYLHluedhpFubbZSVI4TgJK1x4HMPrzro= X-Received: by 2002:a05:6808:6f98:b0:41c:2a71:86e3 with SMTP id 5614622812f47-41d0545e1e2mr15376205b6e.34.1753077547923; Sun, 20 Jul 2025 22:59:07 -0700 (PDT) MIME-Version: 1.0 References: <5f002654-92e9-8032-3e1a-134461b4e819@gmx.net> <90e55c6b-3d79-4bf8-8874-a64dd10a0286@dalibo.com> <4749eb1e-0fd6-f55b-034a-d3c0bbe5ba8b@gmx.net> In-Reply-To: <4749eb1e-0fd6-f55b-034a-d3c0bbe5ba8b@gmx.net> From: Stepan Neretin Date: Mon, 21 Jul 2025 12:58:56 +0700 X-Gm-Features: Ac12FXxEfTxcwNTt8l2cMzavBopQJMFSE7MZ7wY_ZTnk1DM26vfzhfbuOroz4Pk Message-ID: Subject: Re: [PATCH] ALTER TABLE ADD FOREIGN KEY to partitioned table, is not parallelized To: Dimitrios Apostolou Cc: =?UTF-8?B?RnLDqWTDqXJpYyBZaHVlbA==?= , pgsql-performance@lists.postgresql.org, bruce@momjian.us, Christophe Courtois Content-Type: multipart/mixed; boundary="000000000000821772063a6a2cc9" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000821772063a6a2cc9 Content-Type: multipart/alternative; boundary="00000000000082176e063a6a2cc7" --00000000000082176e063a6a2cc7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Jul 21, 2025 at 12:24=E2=80=AFPM Dimitrios Apostolou wrote: > > > > FWIW I implemented a pg_restore --freeze patch, see attached. It needs > > another patch of mine from [1] that implements pg_restore --data-only > > --clean, which for parallel restores encases each COPY in its own > transaction > > and prepends it with a TRUNCATE. All feedback is welcome. > > > > [1] > https://www.postgresql.org/message-id/c61263f2-7472-5dd8-703d-01e683421f6= 1%40gmx.net > > > > It works really fast for the data, and I see that some, but not all > items > > from section=3Dpost-data, start parallel plans. For example I see CREAT= E > INDEX > > spawns parallel workers. > > I added it to July's commitfest, mostly to trigger discussion around the > issue. > > https://commitfest.postgresql.org/patch/5826/ > > Not sure how to mark on the commitfest page that the patch requires > another patch from another commitfest entry. > > > Dimitris > > > > Hello Dimitris and fellow hackers, I'm And Warda(currently unavailable :( ) picking this patch up from the July CommitFest for review. Thanks, Dimitris, for submitting it and for tackling this well-known performance issue with restoring very large databases. The problem of `ALTER TABLE ... ADD FOREIGN KEY` taking days after a restore due to the lack of a visibility map is a significant pain point, and your proposed solution is a logical step. I've reviewed the patch and the discussion in the thread. I've attached a rebased version of the patch against the current master. The core idea of adding a `--freeze` option to `pg_restore` to leverage `COPY ... WITH (FREEZE)` is sound. It directly addresses the problem of needing a very long `VACUUM` run after data loading to make subsequent `post-data` steps, like foreign key validation, performant. The benefit isn't just a minor speedup in the `COPY` itself but the major time-saving of avoiding a full-table `VACUUM` on a massive dataset. I ran a simple performance script based on your patch. On a small test case, I saw a consistent 10-15% speedup during the data-loading phase. While this is encouraging, the main benefit, as noted, is in the steps that follow. =3D=3D=3D Summary =3D=3D=3D freeze average: 1.205 seconds nofreeze average: 1.324 seconds ~/.pg-vanilla/bin =E1=90=85 ./tst.sh =3D=3D=3D Summary =3D=3D=3D freeze average: 1.362 seconds nofreeze average: 1.480 seconds #!/bin/bash set -euo pipefail DUMP_FILE=3D"parttest.dump" DB_PREFIX=3D"parttest" JOBS=3D$(nproc) ROUNDS=3D3 timings() { local mode=3D$1 local total_time=3D0 for i in $(seq 1 $ROUNDS); do DB_NAME=3D"${DB_PREFIX}_${mode}_$i" psql -q -c "DROP DATABASE IF EXISTS $DB_NAME" psql -q -c "CREATE DATABASE $DB_NAME" start_time=3D$(date +%s.%N) if [ "$mode" =3D=3D "freeze" ]; then pg_restore -d "$DB_NAME" -j "$JOBS" --clean --if-exists --freeze "$DUMP_FILE" > /dev/null else pg_restore -d "$DB_NAME" -j "$JOBS" --clean --if-exists "$DUMP_FILE" > /dev/null fi end_time=3D$(date +%s.%N) duration=3D$(echo "$end_time - $start_time" | bc) total_time=3D$(echo "$total_time + $duration" | bc) done average=3D$(echo "scale=3D3; $total_time / $ROUNDS" | bc) echo "$mode average: $average seconds" } freeze_avg=3D$(timings freeze) nofreeze_avg=3D$(timings nofreeze) echo "" echo "=3D=3D=3D Summary =3D=3D=3D" echo "$freeze_avg" echo "$nofreeze_avg" The main area of concern is the implementation method in `pg_backup_archiver.c`. The patch introduces a `do_copy` function that modifies the `COPY` statement string to inject the `WITH (FREEZE)` option. ```c if (cp_end - 10 > cp && strncmp(cp_end - 10, "FROM stdin", 10) =3D=3D 0 ) cp_is_well_formed =3D true; ``` This approach of string parsing is quite fragile. It makes a strong assumption that the `COPY` statement generated by `pg_dump` will always end with `... FROM stdin;` (preceded by optional whitespace). While this is true now, it creates a tight and brittle coupling between `pg_dump`'s output format and `pg_restore`'s parsing logic. Any future changes to `pg_dump` that might add options or slightly alter the `COPY` syntax could break this feature silently or with a non-obvious warning. A more robust solution would be to avoid string manipulation entirely. `pg_restore` should assemble the `COPY` command from its constituent parts (table name, column list, etc.) and then conditionally append the `WITH (FREEZE)` clause before the final `FROM stdin;`. This would decouple the feature from the exact string representation in the dump archive. An alternative=E2=80=94and arguably cleaner=E2=80=94approach might be to sh= ift this logic to pg_dump. One important consideration that needs to be highlighted in the documentation for this feature is the impact on WAL generation. `COPY ... WITH (FREEZE)` is known to generate significantly more WAL traffic because it must log the freezing of tuples, which can be a surprise for users. Maybe we can insert already frozen pages? Additionally, it should be noted that the freeze option only works correctly when performing a fresh load of data into empty tables. Thanks again for your work on this. Regards, Stepan Neretin --00000000000082176e063a6a2cc7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Jul 21, 2025= at 12:24=E2=80=AFPM Dimitrios Apostolou <jimis@gmx.net> wrote:
>
> FWIW I implemented a pg_restore --freeze patch, see attached. It needs=
> another patch of mine from [1] that implements pg_restore --data-only =
> --clean, which for parallel restores encases each COPY in its own tran= saction
> and prepends it with a TRUNCATE. All feedback is welcome.
>
> [1] https:/= /www.postgresql.org/message-id/c61263f2-7472-5dd8-703d-01e683421f61%40gmx.n= et
>
> It works really fast for the data, and I see that some, but not all it= ems
> from section=3Dpost-data, start parallel plans. For example I see CREA= TE INDEX
> spawns parallel workers.

I added it to July's commitfest, mostly to trigger discussion around th= e
issue.

https://commitfest.postgresql.org/patch/5826/

Not sure how to mark on the commitfest page that the patch requires
another patch from another commitfest entry.


Dimitris






Hello Di= mitris and fellow hackers,

I'm And Warda(currently unavailable := ( ) picking this patch up from the July CommitFest for review. Thanks, Dimi= tris, for submitting it and for tackling this well-known performance issue = with restoring very large databases. The problem of `ALTER TABLE ... ADD FO= REIGN KEY` taking days after a restore due to the lack of a visibility map = is a significant pain point, and your proposed solution is a logical step.<= br>
I've reviewed the patch and the discussion in the thread. I'= ve attached a rebased version of the patch against the current master.
<= br>The core idea of adding a `--freeze` option to `pg_restore` to leverage = `COPY ... WITH (FREEZE)` is sound. It directly addresses the problem of nee= ding a very long `VACUUM` run after data loading to make subsequent `post-d= ata` steps, like foreign key validation, performant. The benefit isn't = just a minor speedup in the `COPY` itself but the major time-saving of avoi= ding a full-table `VACUUM` on a massive dataset.

I ran a simple perf= ormance script based on your patch. On a small test case, I saw a consisten= t 10-15% speedup during the data-loading phase. While this is encouraging, = the main benefit, as noted, is in the steps that follow.

=3D=3D=3D S= ummary =3D=3D=3D
freeze average: 1.205 seconds
nofreeze average: 1.32= 4 seconds =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
~/.pg-vanil= la/bin =E1=90=85 ./tst.sh

=3D=3D=3D Summary =3D=3D=3D
freeze aver= age: 1.362 seconds
nofreeze average: 1.480 seconds

#!/bin/bashset -euo pipefail

DUMP_FILE=3D"parttest.dump"
DB_PREFI= X=3D"parttest"
JOBS=3D$(nproc)
ROUNDS=3D3

timings() = {
=C2=A0 local mode=3D$1
=C2=A0 local total_time=3D0

=C2=A0 fo= r i in $(seq 1 $ROUNDS); do
=C2=A0 =C2=A0 DB_NAME=3D"${DB_PREFIX}_$= {mode}_$i"
=C2=A0 =C2=A0 psql -q -c "DROP DATABASE IF EXISTS $= DB_NAME"
=C2=A0 =C2=A0 psql -q -c "CREATE DATABASE $DB_NAME&qu= ot;

=C2=A0 =C2=A0 start_time=3D$(date +%s.%N)

=C2=A0 =C2=A0 i= f [ "$mode" =3D=3D "freeze" ]; then
=C2=A0 =C2=A0 = =C2=A0 pg_restore -d "$DB_NAME" -j "$JOBS" --clean --if= -exists --freeze "$DUMP_FILE" > /dev/null
=C2=A0 =C2=A0 els= e
=C2=A0 =C2=A0 =C2=A0 pg_restore -d "$DB_NAME" -j "$JOBS= " --clean --if-exists "$DUMP_FILE" > /dev/null
=C2=A0 = =C2=A0 fi

=C2=A0 =C2=A0 end_time=3D$(date +%s.%N)
=C2=A0 =C2=A0 d= uration=3D$(echo "$end_time - $start_time" | bc)
=C2=A0 =C2=A0= total_time=3D$(echo "$total_time + $duration" | bc)
=C2=A0 do= ne

=C2=A0 average=3D$(echo "scale=3D3; $total_time / $ROUNDS&qu= ot; | bc)
=C2=A0 echo "$mode average: $average seconds"
}
freeze_avg=3D$(timings freeze)
nofreeze_avg=3D$(timings nofreeze)<= br>
echo ""
echo "=3D=3D=3D Summary =3D=3D=3D"echo "$freeze_avg"
echo "$nofreeze_avg"

The = main area of concern is the implementation method in `pg_backup_archiver.c`= . The patch introduces a `do_copy` function that modifies the `COPY` statem= ent string to inject the `WITH (FREEZE)` option.

```c
if (cp_end = - 10 > cp &&
=C2=A0 =C2=A0 strncmp(cp_end - 10, "FROM st= din", 10) =3D=3D 0
=C2=A0 =C2=A0 )
=C2=A0 =C2=A0 cp_is_well_form= ed =3D true;
```

This approach of string parsing is quite fragile= . It makes a strong assumption that the `COPY` statement generated by `pg_d= ump` will always end with `... FROM stdin;` (preceded by optional whitespac= e). While this is true now, it creates a tight and brittle coupling between= `pg_dump`'s output format and `pg_restore`'s parsing logic. Any fu= ture changes to `pg_dump` that might add options or slightly alter the `COP= Y` syntax could break this feature silently or with a non-obvious warning.<= br>
A more robust solution would be to avoid string manipulation entirel= y. `pg_restore` should assemble the `COPY` command from its constituent par= ts (table name, column list, etc.) and then conditionally append the `WITH = (FREEZE)` clause before the final `FROM stdin;`. This would decouple the fe= ature from the exact string representation in the dump archive.

An a= lternative=E2=80=94and arguably cleaner=E2=80=94approach might be to shift = this logic to pg_dump.

One important consideration that needs to be = highlighted in the documentation for this feature is the impact on WAL gene= ration. `COPY ... WITH (FREEZE)` is known to generate significantly more WA= L traffic because it must log the freezing of tuples, which can be a surpri= se for users. Maybe we can insert already frozen pages?

Additionally= , it should be noted that the freeze option only works correctly when perfo= rming a fresh load of data into empty tables.

Thanks again for your = work on this.

Regards,
Stepan Neretin
=C2=A0
--00000000000082176e063a6a2cc7-- --000000000000821772063a6a2cc9 Content-Type: text/x-patch; charset="US-ASCII"; name="0001-pg_restore-freeze.patch" Content-Disposition: attachment; filename="0001-pg_restore-freeze.patch" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_mdcp37fh0 RnJvbSA5MTJhMGNiM2IzMWQ0ODg0ZmQ2YjJhZTg4NjliOTY0ODNkNjIwNjQxIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBTdGVwYW4gTmVyZXRpbiA8c2xwbWNmQGdtYWlsLmNvbT4KRGF0 ZTogTW9uLCAyMSBKdWwgMjAyNSAxMjoyMjowMiArMDcwMApTdWJqZWN0OiBbUEFUQ0hdIHBnX3Jl c3RvcmUgLS1mcmVlemUKCnBnX3Jlc3RvcmUgbm93IGludm9rZXMKCiAgQ09QWSBGUk9NIC4uLiBX SVRIIChGUkVFWkUpCgpOZWVkcyBhbHNvIG9wdGlvbnMKCiAgLS1zZWN0aW9uPWRhdGEgLS1jbGVh biAtaiBOCgpzbyB0aGF0IGVhY2ggcGdfcmVzdG9yZSB3b3JrZXIgcHJvY2VzcyB3cmFwcyBlYWNo IENPUFkgaW4gYSB0cmFuc2FjdGlvbgphbmQgcHJlY2VkZXMgaXQgd2l0aCBUUlVOQ0FURS4gVGhh dCB3YXkgdGhlIGRhdGEgaW5zZXJ0aW9uIGlzIG9wdGltaXplZAphbmQgdGhlIHZpc2liaWxpdHkg dGFibGUgaXMgd3JpdHRlbiB3aXRob3V0IG5lZWRpbmcgVkFDVVVNaW5nLgoKUmViYXNlZC1ieTog U3RlcGFuIE5lcmV0aW4gPHNscG1jZkBnbWFpbC5jb20+Ci0tLQogc3JjL2Jpbi9wZ19kdW1wL3Bn X2JhY2t1cC5oICAgICAgICAgIHwgIDEgKwogc3JjL2Jpbi9wZ19kdW1wL3BnX2JhY2t1cF9hcmNo aXZlci5jIHwgNDMgKysrKysrKysrKysrKysrKysrKysrKysrKysrLQogc3JjL2Jpbi9wZ19kdW1w L3BnX2R1bXAuYyAgICAgICAgICAgIHwgIDkgKysrKystCiBzcmMvYmluL3BnX2R1bXAvcGdfcmVz dG9yZS5jICAgICAgICAgfCAgNCArKysKIDQgZmlsZXMgY2hhbmdlZCwgNTUgaW5zZXJ0aW9ucygr KSwgMiBkZWxldGlvbnMoLSkKCmRpZmYgLS1naXQgYS9zcmMvYmluL3BnX2R1bXAvcGdfYmFja3Vw LmggYi9zcmMvYmluL3BnX2R1bXAvcGdfYmFja3VwLmgKaW5kZXggYWYwMDA3ZmI2ZDIuLmJlZmI1 MjRjOWQzIDEwMDY0NAotLS0gYS9zcmMvYmluL3BnX2R1bXAvcGdfYmFja3VwLmgKKysrIGIvc3Jj L2Jpbi9wZ19kdW1wL3BnX2JhY2t1cC5oCkBAIC0xMTYsNiArMTE2LDcgQEAgdHlwZWRlZiBzdHJ1 Y3QgX3Jlc3RvcmVPcHRpb25zCiAJaW50CQkJbm9fc2VjdXJpdHlfbGFiZWxzOyAvKiBTa2lwIHNl Y3VyaXR5IGxhYmVsIGVudHJpZXMgKi8KIAlpbnQJCQlub19zdWJzY3JpcHRpb25zOwkvKiBTa2lw IHN1YnNjcmlwdGlvbiBlbnRyaWVzICovCiAJaW50CQkJc3RyaWN0X25hbWVzOworCWludAkJCWZy ZWV6ZTsJCQkvKiBDT1BZIEZSRUVaRSAqLwogCiAJY29uc3QgY2hhciAqZmlsZW5hbWU7CiAJaW50 CQkJZHVtcFNlY3Rpb25zOwpkaWZmIC0tZ2l0IGEvc3JjL2Jpbi9wZ19kdW1wL3BnX2JhY2t1cF9h cmNoaXZlci5jIGIvc3JjL2Jpbi9wZ19kdW1wL3BnX2JhY2t1cF9hcmNoaXZlci5jCmluZGV4IDMw ZTBkYTMxYWEzLi5mMTkwY2E3NzgzNiAxMDA2NDQKLS0tIGEvc3JjL2Jpbi9wZ19kdW1wL3BnX2Jh Y2t1cF9hcmNoaXZlci5jCisrKyBiL3NyYy9iaW4vcGdfZHVtcC9wZ19iYWNrdXBfYXJjaGl2ZXIu YwpAQCAtOTksNiArOTksOSBAQCBzdGF0aWMgdm9pZCByZXN0b3JlX3RvY19lbnRyaWVzX3BhcmFs bGVsKEFyY2hpdmVIYW5kbGUgKkFILAogCQkJCQkJCQkJCSBUb2NFbnRyeSAqcGVuZGluZ19saXN0 KTsKIHN0YXRpYyB2b2lkIHJlc3RvcmVfdG9jX2VudHJpZXNfcG9zdGZvcmsoQXJjaGl2ZUhhbmRs ZSAqQUgsCiAJCQkJCQkJCQkJIFRvY0VudHJ5ICpwZW5kaW5nX2xpc3QpOworc3RhdGljIHZvaWQg ZG9fY29weShBcmNoaXZlSGFuZGxlICpBSCwKKwkJCQkJY29uc3QgY2hhciAqY3AsCisJCQkJCWJv b2wgZnJlZXplKTsKIHN0YXRpYyB2b2lkIHBlbmRpbmdfbGlzdF9oZWFkZXJfaW5pdChUb2NFbnRy eSAqbCk7CiBzdGF0aWMgdm9pZCBwZW5kaW5nX2xpc3RfYXBwZW5kKFRvY0VudHJ5ICpsLCBUb2NF bnRyeSAqdGUpOwogc3RhdGljIHZvaWQgcGVuZGluZ19saXN0X3JlbW92ZShUb2NFbnRyeSAqdGUp OwpAQCAtMTAyMSw3ICsxMDI0LDcgQEAgcmVzdG9yZV90b2NfZW50cnkoQXJjaGl2ZUhhbmRsZSAq QUgsIFRvY0VudHJ5ICp0ZSwgYm9vbCBpc19wYXJhbGxlbCkKIAkJCQkJICovCiAJCQkJCWlmICh0 ZS0+Y29weVN0bXQgJiYgc3RybGVuKHRlLT5jb3B5U3RtdCkgPiAwKQogCQkJCQl7Ci0JCQkJCQlh aHByaW50ZihBSCwgIiVzIiwgdGUtPmNvcHlTdG10KTsKKwkJCQkJCWRvX2NvcHkoQUgsIHRlLT5j b3B5U3RtdCwgcm9wdC0+ZnJlZXplKTsKIAkJCQkJCUFILT5vdXRwdXRLaW5kID0gT1VUUFVUX0NP UFlEQVRBOwogCQkJCQl9CiAJCQkJCWVsc2UKQEAgLTEwODQsNiArMTA4Nyw0NCBAQCByZXN0b3Jl X3RvY19lbnRyeShBcmNoaXZlSGFuZGxlICpBSCwgVG9jRW50cnkgKnRlLCBib29sIGlzX3BhcmFs bGVsKQogCXJldHVybiBzdGF0dXM7CiB9CiAKK3N0YXRpYyB2b2lkCitkb19jb3B5KEFyY2hpdmVI YW5kbGUgKkFILCBjb25zdCBjaGFyICpjcCwgYm9vbCBmcmVlemUpCit7CisJY29uc3Qgc2l6ZV90 IGNwX2xlbiA9IHN0cmxlbihjcCk7CisJYm9vbAkJY3BfaXNfd2VsbF9mb3JtZWQgPSBmYWxzZTsK Kwljb25zdCBjaGFyICpjcF9lbmQ7CisKKwlBc3NlcnQoY3BfbGVuID4gMCk7CQkJLyogSGF2ZSBj aGVja2VkIGl0IGluIGNhbGxlciAqLworCisJLyoKKwkgKiBDaGVjayBpZiB0aGUgQ09QWSBzdGF0 ZW1lbnQgaXMgd2VsbCB3cml0dGVuIHNvIHRoYXQgd2UgY2FuIGluamVjdCB0aGUKKwkgKiBGUkVF WkUgb3B0aW9uLgorCSAqLworCWlmIChmcmVlemUpCisJeworCQlpbnQJCQlpID0gY3BfbGVuIC0g MTsKKworCQkvKiBDdXQgb2ZmIHRoZSB0cmFpbGluZyBzZW1pY29sb24gYW5kIHdoaXRlc3BhY2Uu ICovCisJCXdoaWxlIChpID4gMCAmJgorCQkJICAgKGNwW2ldID09ICcgJyB8fCBjcFtpXSA9PSAn XG4nIHx8IGNwW2ldID09ICc7JykpCisJCQlpLS07CisJCWNwX2VuZCA9ICZjcFtpICsgMV07CisK KwkJaWYgKGNwX2VuZCAtIDEwID4gY3AgJiYKKwkJCXN0cm5jbXAoY3BfZW5kIC0gMTAsICJGUk9N IHN0ZGluIiwgMTApID09IDAKKwkJCSkKKwkJCWNwX2lzX3dlbGxfZm9ybWVkID0gdHJ1ZTsKKwkJ ZWxzZQorCQkJcGdfbG9nX3dhcm5pbmcoIkNPUFkgc3RhdGVtZW50IGZyb20gZHVtcCBmaWxlIGlz IG5vdCBpbiB0aGUgcmlnaHQgZm9ybTsgV2lsbCBub3QgaW5qZWN0IHRoZSBGUkVFWkUgb3B0aW9u Iik7CisJfQorCisJaWYgKGZyZWV6ZSAmJiBjcF9pc193ZWxsX2Zvcm1lZCkKKwkJYWhwcmludGYo QUgsICIlLipzIFdJVEggKEZSRUVaRSk7XG4iLAorCQkJCSAoaW50KSAoY3BfZW5kIC0gY3ApLCBj cCk7CisJZWxzZQorCQlhaHByaW50ZihBSCwgIiVzIiwgY3ApOworfQorCiAvKgogICogQWxsb2Nh dGUgYSBuZXcgUmVzdG9yZU9wdGlvbnMgYmxvY2suCiAgKiBUaGlzIGlzIG1haW5seSBzbyB3ZSBj YW4gaW5pdGlhbGl6ZSBpdCwgYnV0IGFsc28gZm9yIGZ1dHVyZSBleHBhbnNpb24sCmRpZmYgLS1n aXQgYS9zcmMvYmluL3BnX2R1bXAvcGdfZHVtcC5jIGIvc3JjL2Jpbi9wZ19kdW1wL3BnX2R1bXAu YwppbmRleCA2MDRmYzEwOTQxNi4uZTY5YzNkNmI5OWIgMTAwNjQ0Ci0tLSBhL3NyYy9iaW4vcGdf ZHVtcC9wZ19kdW1wLmMKKysrIGIvc3JjL2Jpbi9wZ19kdW1wL3BnX2R1bXAuYwpAQCAtMjg1Niw3 ICsyODU2LDE0IEBAIGR1bXBUYWJsZURhdGEoQXJjaGl2ZSAqZm91dCwgY29uc3QgVGFibGVEYXRh SW5mbyAqdGRpbmZvKQogCiAJaWYgKGRvcHQtPmR1bXBfaW5zZXJ0cyA9PSAwKQogCXsKLQkJLyog RHVtcC9yZXN0b3JlIHVzaW5nIENPUFkgKi8KKwkJLyoKKwkJICogRHVtcC9yZXN0b3JlIHVzaW5n IENPUFkuCisJCSAqCisJCSAqIE5PVEU6IGRvIG5vdCB1c2Ugb3B0aW9ucyBpbiB0aGUgQ09QWSBz dGF0ZW1lbnQsIGFzIHRoZSByZXN0b3JlCisJCSAqIHByb2Nlc3MgYXBwZW5kcyBpdHMgb3duIG9w dGlvbnMuIEluIGZhY3QgcGdfcmVzdG9yZSBhbHdheXMgZXhwZWN0cworCQkgKgorCQkgKiBDT1BZ IC4uLiBGUk9NIHN0ZGluOworCQkgKi8KIAkJZHVtcEZuID0gZHVtcFRhYmxlRGF0YV9jb3B5Owog CQkvKiBtdXN0IHVzZSAyIHN0ZXBzIGhlcmUgJ2NhdXNlIGZtdElkIGlzIG5vbnJlZW50cmFudCAq LwogCQlwcmludGZQUUV4cEJ1ZmZlcihjb3B5QnVmLCAiQ09QWSAlcyAiLApkaWZmIC0tZ2l0IGEv c3JjL2Jpbi9wZ19kdW1wL3BnX3Jlc3RvcmUuYyBiL3NyYy9iaW4vcGdfZHVtcC9wZ19yZXN0b3Jl LmMKaW5kZXggNmVmNzg5Y2IwNmQuLmY5YTY1OWRlMTZlIDEwMDY0NAotLS0gYS9zcmMvYmluL3Bn X2R1bXAvcGdfcmVzdG9yZS5jCisrKyBiL3NyYy9iaW4vcGdfZHVtcC9wZ19yZXN0b3JlLmMKQEAg LTExNCw2ICsxMTQsNyBAQCBtYWluKGludCBhcmdjLCBjaGFyICoqYXJndikKIAlzdGF0aWMgaW50 CXdpdGhfZGF0YSA9IDA7CiAJc3RhdGljIGludAl3aXRoX3NjaGVtYSA9IDA7CiAJc3RhdGljIGlu dAl3aXRoX3N0YXRpc3RpY3MgPSAwOworCXN0YXRpYyBpbnQJZnJlZXplID0gMDsKIAogCXN0cnVj dCBvcHRpb24gY21kb3B0c1tdID0gewogCQl7ImNsZWFuIiwgMCwgTlVMTCwgJ2MnfSwKQEAgLTE3 NSw2ICsxNzYsNyBAQCBtYWluKGludCBhcmdjLCBjaGFyICoqYXJndikKIAkJeyJzdGF0aXN0aWNz LW9ubHkiLCBub19hcmd1bWVudCwgJnN0YXRpc3RpY3Nfb25seSwgMX0sCiAJCXsiZmlsdGVyIiwg cmVxdWlyZWRfYXJndW1lbnQsIE5VTEwsIDR9LAogCQl7ImV4Y2x1ZGUtZGF0YWJhc2UiLCByZXF1 aXJlZF9hcmd1bWVudCwgTlVMTCwgNn0sCisJCXsiZnJlZXplIiwgbm9fYXJndW1lbnQsICZmcmVl emUsIDF9LAogCiAJCXtOVUxMLCAwLCBOVUxMLCAwfQogCX07CkBAIC00NjcsNiArNDY5LDcgQEAg bWFpbihpbnQgYXJnYywgY2hhciAqKmFyZ3YpCiAJb3B0cy0+bm9fcHVibGljYXRpb25zID0gbm9f cHVibGljYXRpb25zOwogCW9wdHMtPm5vX3NlY3VyaXR5X2xhYmVscyA9IG5vX3NlY3VyaXR5X2xh YmVsczsKIAlvcHRzLT5ub19zdWJzY3JpcHRpb25zID0gbm9fc3Vic2NyaXB0aW9uczsKKwlvcHRz LT5mcmVlemUgPSBmcmVlemU7CiAKIAlpZiAoaWZfZXhpc3RzICYmICFvcHRzLT5kcm9wU2NoZW1h KQogCQlwZ19mYXRhbCgib3B0aW9uIC0taWYtZXhpc3RzIHJlcXVpcmVzIG9wdGlvbiAtYy8tLWNs ZWFuIik7CkBAIC03MTUsNiArNzE4LDcgQEAgdXNhZ2UoY29uc3QgY2hhciAqcHJvZ25hbWUpCiAJ cHJpbnRmKF8oIiAgLS13aXRoLWRhdGEgICAgICAgICAgICAgICAgICByZXN0b3JlIHRoZSBkYXRh XG4iKSk7CiAJcHJpbnRmKF8oIiAgLS13aXRoLXNjaGVtYSAgICAgICAgICAgICAgICByZXN0b3Jl IHRoZSBzY2hlbWFcbiIpKTsKIAlwcmludGYoXygiICAtLXdpdGgtc3RhdGlzdGljcyAgICAgICAg ICAgIHJlc3RvcmUgdGhlIHN0YXRpc3RpY3NcbiIpKTsKKwlwcmludGYoXygiICAtLWZyZWV6ZSAg ICAgICAgICAgICAgICAgICAgIENPUFkgRlJFRVpFIChyZWFkIHRoZSBtYW51YWwgZm9yIGNhdmVh dHMpXG4iKSk7CiAKIAlwcmludGYoXygiXG5Db25uZWN0aW9uIG9wdGlvbnM6XG4iKSk7CiAJcHJp bnRmKF8oIiAgLWgsIC0taG9zdD1IT1NUTkFNRSAgICAgIGRhdGFiYXNlIHNlcnZlciBob3N0IG9y IHNvY2tldCBkaXJlY3RvcnlcbiIpKTsKLS0gCjIuNDguMQoK --000000000000821772063a6a2cc9--