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 1vGXVV-00HYV4-Fg for pgsql-hackers@arkaria.postgresql.org; Wed, 05 Nov 2025 07:00:37 +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 1vGXVU-000m2r-FK for pgsql-hackers@arkaria.postgresql.org; Wed, 05 Nov 2025 07:00:35 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1vGXVT-000m2g-SC for pgsql-hackers@lists.postgresql.org; Wed, 05 Nov 2025 07:00:35 +0000 Received: from mail-ua1-x933.google.com ([2607:f8b0:4864:20::933]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1vGXVP-005XWn-0g for pgsql-hackers@lists.postgresql.org; Wed, 05 Nov 2025 07:00:33 +0000 Received: by mail-ua1-x933.google.com with SMTP id a1e0cc1a2514c-935356590ddso1081179241.1 for ; Tue, 04 Nov 2025 23:00:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=enterprisedb.com; s=google; t=1762326030; x=1762930830; 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=HL40saWoiN3YDfJ4Cb0KRph7fbctOnK+A+Y08Z0kxMo=; b=c6oOzh+JTN5ynPJWATcFS1kzQkYUN6m8ZxSuqypaglstu8smD1SLM735icfujkfquw vrv+/dkKQSIHXlcmYqknUKLJSFxu0PwrMVIbj7WY04BSbiHKgzqRj4MIRkYUcO/UKfZG fmrIqsJv2+qgWpDQYP1+fLOPMO2JhZmqRPYZI9oOjMa0RbS0mtWTlvdjmTYmhToyR0pE vH73rMOES5iPga6LEKWcSOxNcKaZpWOtvSfr4AVUinBYK9CuVFfD0/QwXpStO0NUV2Tn XD3LnVyNSk4knhWneCASlTNshpmU4JxNO+gxVMaODFGM4/pi3ct+3tOdLrTDSoz8QKD1 ArQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1762326030; x=1762930830; 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=HL40saWoiN3YDfJ4Cb0KRph7fbctOnK+A+Y08Z0kxMo=; b=L4RCvFegwMHyTfA9QPg8Wi8Lyu3BguPiERvOO5NfiFiJ0HBlSTJVtYy6oBAXkq3WSt MTN/J0FEkaBcrsWpUhcBK/M3bhSp036POFkvqD+oHuVcOmXGMc/YdG+bweUMTb785rzu k0XdOGjILY8W8QdkFLbDXuVREevSKTx8Ju/tVE7WoFSlVuBwOFj6Ag5/GJAOlDfQnR9N LiT5Jg7zNttDZynLMmCtCnDFLJm9caNYqKHWwVF3Ib5GIA3X/jOXgf/M8R8rJbs5WQRZ llwKojZeONwXZgiQ+tCMnce1Qt7TG3JvBv2sIT4vblyWUy/sePxE6bKM1LliBuvIJZpN H3qg== X-Gm-Message-State: AOJu0YyvaJN044cDP9aIeYujeGCtJ3t7FmLI+Mn41VlxhdrqQx7q5ETJ nZz3XQh+1kUmnsh5mbxTvTmUlkgTTMFIuPeFaGZnN2Jn1SZhmJ7LPv3mhvmVcY4D4O74QcIsIzk 97r13cf8qRUjVBIfNefsQI9wQlMC7khUbjMmhYdj3 X-Gm-Gg: ASbGncvWcR5Zv8il034FrEhsNrYpk4B3xXiGaz6CHrZSsCAxrpjvp9Q7lRald3o3EbO lEup8RdrHMyIcPly06Mn6N9dj4BqJjLhsgvFibVLkHX52PmcZUCRVg5iXlxHak61NzeDdbJSlDb w02GeXzlsWvTe1MiOZdtcn+rOknOiFlVLoOG7YX712Y3LECE5zv0HxGUpRFNWLcIFIu2yXwE6bK zAnSpq3YeokZoH+VJ7BliaJuIwHY+70tAtf6/OHMKtl0HF6p8+EH/xko1N37Ig= X-Google-Smtp-Source: AGHT+IEoN6q3NPJhZNFn255KbLI/74hYnM6cJ8LlRjWJRHqtsHw1ArkWZxcpbYVmw4k/vMXwUuxsIN2m705cHVGqYJ8= X-Received: by 2002:a05:6102:38cb:b0:5db:ebb4:fde3 with SMTP id ada2fe7eead31-5dd89140653mr651594137.16.1762326029544; Tue, 04 Nov 2025 23:00:29 -0800 (PST) MIME-Version: 1.0 References: <3f22a8bb-29e8-40cc-97a1-309181da2c13@dunslane.net> <20250722005339.ca.nmisch@google.com> <20250725162141.6f.nmisch@google.com> <2225040.1753477169@sss.pgh.pa.us> <20250727235628.e2.nmisch@google.com> <8f2ad50b-ebb7-4adc-997e-25e0ad96ff34@dunslane.net> <2bed001a-462c-42da-9a6b-3c7884502932@dunslane.net> <20250824010811.4d.nmisch@google.com> <82eb35b8-7f07-493b-b689-0934919e1dc3@dunslane.net> In-Reply-To: From: Vaibhav Dalvi Date: Wed, 5 Nov 2025 12:29:53 +0530 X-Gm-Features: AWmQ_bmtHuVeO6IcR2wbYOfcb_VX7MKgsEhl0Tv-nUW32VHVe2XF8fp9_UtfSgI Message-ID: Subject: Re: Non-text mode for pg_dumpall To: Mahendra Singh Thalor Cc: pgsql-hackers@lists.postgresql.org Content-Type: multipart/mixed; boundary="000000000000f866330642d380e4" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000f866330642d380e4 Content-Type: multipart/alternative; boundary="000000000000f866320642d380e2" --000000000000f866320642d380e2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Mahendra, Thank you for the fix. Please find my further review comments below. ### Restrict-Key Option The `--restrict-key` option is currently being accepted by `pg_dumpall` even when non-plain formats are specified, which contradicts its intended use only with the plain format. For example: ``` $ ./db/bin/pg_dump --format=3Dd -f testdump_dir --restrict-key=3DRESTRICT_K= EY pg_dump: error: option --restrict-key can only be used with --format=3Dplai= n $ ./db/bin/pg_dumpall --format=3Dd -f testdump_dir --restrict-key=3DRESTRIC= T_KEY pg_dumpall: error: invalid restrict key ``` I have attached a delta patch that addresses the issue with the `--restrict-key` option. It would be beneficial to include a dedicated test case for this check. ### Use of Dump Options Structure (dopt) Please ensure consistency by utilizing the main dump options structure (`dopt`) instead of declaring and using individual variables where the structure already provides fields. For example, the `output_clean` variable seems redundant here: ```c case 'c': output_clean =3D true; dopt.outputClean =3D 1; break; ``` In my attached delta file, I have replaced the unnecessary `restrict_key` variable with `dopt.restrict_key`. ### Cosmetic Issues 1. Please review the spacing around the pointer: ```c + ((ArchiveHandle * )fout) ->connection =3D conn; + ((ArchiveHandle * ) fout) -> public.numWorkers =3D 1; ``` 2. Please be consistent with the punctuation of single-line comments; some end with a full stop (`.`) and others do not. 3. In the SGML documentation changes, some new statements start with one space, and others start with two. Please adhere to a single standard for indentation across the patch. Regards, Vaibhav EnterpriseDB On Mon, Nov 3, 2025 at 5:24=E2=80=AFPM Mahendra Singh Thalor wrote: > On Mon, 3 Nov 2025 at 12:06, Vaibhav Dalvi > wrote: > > > > Hi Mahendra, > > > > Thank you for your work on this feature. > > I have just begun reviewing the latest patch and > > encountered the following errors during the initial setup: > > > > ``` > > $ ./db/bin/pg_restore testdump_dir -C -d postgres -F d -p 5556 > > pg_restore: error: could not execute query: ERROR: syntax error at or > near "\\" > > LINE 1: \restrict aO9K1gzVZTlafidF5fWx8ADGzUnIiAcguFz5qskGaFDygTCjCj... > > ^ > > Command was: \restrict > aO9K1gzVZTlafidF5fWx8ADGzUnIiAcguFz5qskGaFDygTCjCj9vg3Xxys1b3hb > > > > pg_restore: error: could not execute query: ERROR: syntax error at or > near "\\" > > LINE 1: \unrestrict aO9K1gzVZTlafidF5fWx8ADGzUnIiAcguFz5qskGaFDygTCj... > > ^ > > Command was: \unrestrict > aO9K1gzVZTlafidF5fWx8ADGzUnIiAcguFz5qskGaFDygTCjCj9vg3Xxys1b3hb > > > > pg_restore: error: could not execute query: ERROR: syntax error at or > near "\\" > > LINE 1: \connect template1 > > ^ > > Command was: \connect template1 > > > > pg_restore: error: could not execute query: ERROR: syntax error at or > near "\\" > > LINE 1: \connect postgres > > ^ > > Command was: \connect postgres > > ``` > > To cross-check tried with plain dump(with pg_dumpall) and > > restored(SQL file restore) without patch and didn't get above > > connection errors. > > > > It appears there might be an issue with the dump file itself. > > Please note that this is my first observation as I have just > > started the review. I will continue with my assessment. > > > > Regards, > > Vaibhav Dalvi > > EnterpriseDB > > Thanks Vaibhav for the review. > This change was added by me in v04. Only in the case of a file, we should > restore these commands. Attached patch is fixing the same. > > If we dump and restore the same file with the same user, then we will get > an error of ROLE CREATE as the same role is already created. I think, > either we can ignore this error, or we can keep it as a restore can be do= ne > with different users. > >> mst@localhost bin]$ ./pg_restore d1 -C -d postgres >> pg_restore: error: could not execute query: ERROR: role "mst" already >> exists >> Command was: CREATE ROLE mst; >> ALTER ROLE mst WITH SUPERUSER INHERIT CREATEROLE CREATEDB LOGIN >> REPLICATION BYPASSRLS; >> >> >> pg_restore: warning: errors ignored on restore: 1 > > > > > > > On Fri, Oct 31, 2025 at 2:51=E2=80=AFPM Mahendra Singh Thalor < > mahi6run@gmail.com> wrote: > >> > >> On Tue, 28 Oct 2025 at 11:32, Mahendra Singh Thalor > wrote: > >> > > >> > On Thu, 16 Oct 2025 at 16:24, Mahendra Singh Thalor < > mahi6run@gmail.com> wrote: > >> > > > >> > > On Wed, 15 Oct 2025 at 23:05, Mahendra Singh Thalor < > mahi6run@gmail.com> wrote: > >> > > > > >> > > > On Sun, 24 Aug 2025 at 22:12, Andrew Dunstan > wrote: > >> > > > > > >> > > > > > >> > > > > On 2025-08-23 Sa 9:08 PM, Noah Misch wrote: > >> > > > > > >> > > > > On Wed, Jul 30, 2025 at 02:51:59PM -0400, Andrew Dunstan wrote= : > >> > > > > > >> > > > > OK, now that's reverted we should discuss how to proceed. I ha= d > two thoughts > >> > > > > - we could use invent a JSON format for the globals, or we > could just use > >> > > > > the existing archive format. I think the archive format is > pretty flexible, > >> > > > > and should be able to accommodate this. The downside is it's > not humanly > >> > > > > readable. The upside is that we don't need to do anything > special either to > >> > > > > write it or parse it. > >> > > > > > >> > > > > I would first try to use the existing archiver API, because > that makes it > >> > > > > harder to miss bugs. Any tension between that API and > pg_dumpall is likely to > >> > > > > have corresponding tension on the pg_restore side. Resolving > that tension > >> > > > > will reveal much of the project's scope that remained hidden > during the v18 > >> > > > > attempt. Perhaps more important than that, using the archiver > API means > >> > > > > future pg_dump and pg_restore options are more likely to > cooperate properly > >> > > > > with $SUBJECT. In other words, I want it to be hard to add > pg_dump/pg_restore > >> > > > > features that malfunction only for $SUBJECT archives. The > strength of the > >> > > > > archiver architecture shows in how rarely new features need > format-specific > >> > > > > logic and how rarely format-specific bugs get reported. We've > had little or > >> > > > > no trouble with e.g. bugs that appear in -Fd but not in -Fc. > >> > > > > > >> > > > > > >> > > > > Yeah, that's what we're going to try. > >> > > > > > >> > > > > > >> > > > > cheers > >> > > > > > >> > > > > > >> > > > > andrew > >> > > > > > >> > > > > -- > >> > > > > Andrew Dunstan > >> > > > > EDB: https://www.enterprisedb.com > >> > > > > >> > > > Thanks Andrew, Noah and all others for feedback. > >> > > > > >> > > > Based on the above suggestions and discussions, I removed sql > commands > >> > > > from the global.dat file. For global commands, now we are making > >> > > > toc.dat/toc.dmp/toc.tar file based on format specified and based > on > >> > > > format specified, we are making archive entries for these global > >> > > > commands. By this approach, we removed the hard-coded parsing > part of > >> > > > the global.dat file and we are able to skip DROP DATABASE with t= he > >> > > > globals-only option. > >> > > > > >> > > > Here, I am attaching a patch for review, testing and feedback. > This is > >> > > > a WIP patch. I will do some more code cleanup and will add some > more > >> > > > comments also. Please review this and let me know design level > >> > > > feedback. Thanks Tushar Ahuja for some internal testing and > feedback. > >> > > > > >> > > > >> > > Hi, > >> > > Here, I am attaching an updated patch. In offline discussion, Andr= ew > >> > > reported some test-case failures(Thanks Andrew). I fixed those. > >> > > Please let me know feedback for the patch. > >> > > > >> > > >> > Hi, > >> > Here I am attaching a re-based patch as v02 was failing on head. > >> > Thanks Tushar for the testing. > >> > Please review this and let me know feedback. > >> > > >> > >> Hi all, > >> Here I am attaching an updated patch for review and testing. Based on > >> some offline comments by Andrew, I did some code cleanup. > >> Please consider this patch for feedback. > >> > >> -- > >> Thanks and Regards > >> Mahendra Singh Thalor > >> EnterpriseDB: http://www.enterprisedb.com > > > > -- > Thanks and Regards > Mahendra Singh Thalor > EnterpriseDB: http://www.enterprisedb.com > --000000000000f866320642d380e2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Mahendra,

Thank you for t= he fix. Please find my further review comments below.

<= div>### Restrict-Key Option

The `--restrict-key` o= ption is currently being accepted by
`pg_dumpall` even when non-p= lain formats are specified,
which contradicts its intended use on= ly with the plain format.

For example:
<= br>
```
$ ./db/bin/pg_dump --format=3Dd -f testdump_dir= --restrict-key=3DRESTRICT_KEY
pg_dump: error: option --restrict-= key can only be used with --format=3Dplain
$ ./db/bin/pg_dumpall = --format=3Dd -f testdump_dir --restrict-key=3DRESTRICT_KEY
pg_dum= pall: error: invalid restrict key
```

I = have attached a delta patch that addresses the issue with the
`--= restrict-key` option. It would be beneficial to include a dedicated
test case for this check.

### Use of Dump Optio= ns Structure (dopt)

Please ensure consistency by u= tilizing the main dump options
structure (`dopt`) instead of decl= aring and using individual variables
where the structure already = provides fields. For example, the
`output_clean` variable seems r= edundant here:

```c
case 'c':
output_clean =3D true;
dopt.outputClean =3D 1;
break;
```

In my attached de= lta file, I have replaced the unnecessary
`restrict_key` variable= with `dopt.restrict_key`.

### Cosmetic Issues

1. Please review the spacing around the pointer:
```c
+ ((ArchiveHandle * )fout) ->connection = =3D conn;
+ ((ArchiveHandle * ) fout) -> public.numWorker= s =3D 1;
```
2. Please be consistent with the punct= uation of single-line comments;=C2=A0
=C2=A0 =C2=A0 some end with= a full stop (`.`) and others do not.
3. In the SGML documentatio= n changes, some new statements start
=C2=A0 =C2=A0 with one space= , and others start with two. Please adhere to a single
=C2=A0 =C2= =A0 standard for indentation across the patch.

Reg= ards,
Vaibhav
EnterpriseDB

O= n Mon, Nov 3, 2025 at 5:24=E2=80=AFPM Mahendra Singh Thalor <mahi6run@gmail.com> wrote:
On Mon, 3 Nov= 2025 at 12:06, Vaibhav Dalvi <vaibhav.dalvi@enterprisedb.com> wrote:>
> Hi Mahendra,
>
> Thank you for your work on this = feature.
> I have just begun reviewing the latest patch and
> e= ncountered the following errors during the initial setup:
>
> `= ``
> $ ./db/bin/pg_restore testdump_dir -C -d postgres -F d -p 5556> pg_restore: error: could not execute query: ERROR: syntax error at o= r near "\\"
> LINE 1: \restrict aO9K1gzVZTlafidF5fWx8ADGzUn= IiAcguFz5qskGaFDygTCjCj...
> ^
> Command was: \restrict aO9K1gz= VZTlafidF5fWx8ADGzUnIiAcguFz5qskGaFDygTCjCj9vg3Xxys1b3hb
>
> pg= _restore: error: could not execute query: ERROR: syntax error at or near &q= uot;\\"
> LINE 1: \unrestrict aO9K1gzVZTlafidF5fWx8ADGzUnIiAcguF= z5qskGaFDygTCj...
> ^
> Command was: \unrestrict aO9K1gzVZTlafi= dF5fWx8ADGzUnIiAcguFz5qskGaFDygTCjCj9vg3Xxys1b3hb
>
> pg_restor= e: error: could not execute query: ERROR: syntax error at or near "\\&= quot;
> LINE 1: \connect template1
> ^
> Command was: \co= nnect template1
>
> pg_restore: error: could not execute query:= ERROR: syntax error at or near "\\"
> LINE 1: \connect pos= tgres
> ^
> Command was: \connect postgres
> ```
> = To cross-check tried with plain dump(with pg_dumpall) and
> =C2=A0res= tored(SQL file restore) without patch and didn't get above
> conn= ection errors.
>
> It appears there might be an issue with the = dump file itself.
> Please note that this is my first observation as = I have just
> started the review. I will continue with my assessment.=
>
> Regards,
> Vaibhav Dalvi
> EnterpriseDB
Thanks Vaibhav for the review.
This change was added by me in v04. Only= in the case of a file, we should restore these commands. Attached patch is= fixing the same.

If we dump and restore the same file with the same= user, then we will get an error of ROLE CREATE as the same role is already= created. I think, either we can ignore this error, or we can keep it as a = restore can be done with different users.
mst@localhost bin]$ ./pg_restore d1 =C2=A0-C -d postgre= s
pg_restore: error: could not execute query: ERROR: =C2=A0role "ms= t" already exists
Command was: CREATE ROLE mst;
ALTER ROLE mst W= ITH SUPERUSER INHERIT CREATEROLE CREATEDB LOGIN REPLICATION BYPASSRLS;
<= br>
pg_restore: warning: errors ignored on restore: 1
<= br>
>
> On Fri, Oct 31, 2025 at 2:51=E2=80=AFPM Mahendra Singh = Thalor <mahi6run= @gmail.com> wrote:
>>
>> On Tue, 28 Oct 2025 at 11= :32, Mahendra Singh Thalor <mahi6run@gmail.com> wrote:
>> >
>> = > On Thu, 16 Oct 2025 at 16:24, Mahendra Singh Thalor <mahi6run@gmail.com> wrote:=
>> > >
>> > > On Wed, 15 Oct 2025 at 23:05, = Mahendra Singh Thalor <mahi6run@gmail.com> wrote:
>> > > >
>= > > > > On Sun, 24 Aug 2025 at 22:12, Andrew Dunstan <andrew@dunslane.net&= gt; wrote:
>> > > > >
>> > > > ><= br>>> > > > > On 2025-08-23 Sa 9:08 PM, Noah Misch wrote:=
>> > > > >
>> > > > > On Wed, Ju= l 30, 2025 at 02:51:59PM -0400, Andrew Dunstan wrote:
>> > >= > >
>> > > > > OK, now that's reverted we s= hould discuss how to proceed. I had two thoughts
>> > > >= > - we could use invent a JSON format for the globals, or we could just= use
>> > > > > the existing archive format. I think t= he archive format is pretty flexible,
>> > > > > and s= hould be able to accommodate this. The downside is it's not humanly
= >> > > > > readable. The upside is that we don't need= to do anything special either to
>> > > > > write it = or parse it.
>> > > > >
>> > > > >= ; I would first try to use the existing archiver API, because that makes it=
>> > > > > harder to miss bugs.=C2=A0 Any tension bet= ween that API and pg_dumpall is likely to
>> > > > > h= ave corresponding tension on the pg_restore side.=C2=A0 Resolving that tens= ion
>> > > > > will reveal much of the project's s= cope that remained hidden during the v18
>> > > > > at= tempt.=C2=A0 Perhaps more important than that, using the archiver API means=
>> > > > > future pg_dump and pg_restore options are = more likely to cooperate properly
>> > > > > with $SUB= JECT.=C2=A0 In other words, I want it to be hard to add pg_dump/pg_restore<= br>>> > > > > features that malfunction only for $SUBJECT= archives.=C2=A0 The strength of the
>> > > > > archiv= er architecture shows in how rarely new features need format-specific
&g= t;> > > > > logic and how rarely format-specific bugs get re= ported.=C2=A0 We've had little or
>> > > > > no tr= ouble with e.g. bugs that appear in -Fd but not in -Fc.
>> > &g= t; > >
>> > > > >
>> > > > >= ; Yeah, that's what we're going to try.
>> > > > = >
>> > > > >
>> > > > > cheers=
>> > > > >
>> > > > >
>>= ; > > > > andrew
>> > > > >
>> &g= t; > > > --
>> > > > > Andrew Dunstan
>= > > > > > EDB: https://www.enterprisedb.com
>> > > >>> > > > Thanks Andrew, Noah and all others for feedback.<= br>>> > > >
>> > > > Based on the above su= ggestions and discussions, I removed sql commands
>> > > >= ; from the global.dat file. For global commands, now we are making
>&= gt; > > > toc.dat/toc.dmp/toc.tar file based on format specified a= nd based on
>> > > > format specified, we are making arch= ive entries for these global
>> > > > commands. By this a= pproach, we removed the hard-coded parsing part of
>> > > &g= t; the global.dat file and we are able to skip DROP DATABASE with the
&g= t;> > > > globals-only option.
>> > > >
&g= t;> > > > Here, I am attaching a patch for review, testing and = feedback. This is
>> > > > a WIP patch. I will do some mo= re code cleanup and will add some more
>> > > > comments = also. Please review this and let me know design level
>> > >= > feedback. Thanks Tushar Ahuja for some internal testing and feedback.=
>> > > >
>> > >
>> > > Hi,=
>> > > Here, I am attaching an updated patch. In offline di= scussion, Andrew
>> > > reported some test-case failures(Tha= nks Andrew). I fixed those.
>> > > Please let me know feedba= ck for the patch.
>> > >
>> >
>> > H= i,
>> > Here I am attaching a re-based patch as v02 was failing= on head.
>> > Thanks Tushar for the testing.
>> > = Please review this and let me know feedback.
>> >
>>>> Hi all,
>> Here I am attaching an updated patch for rev= iew and testing. Based on
>> some offline comments by Andrew, I di= d some code cleanup.
>> Please consider this patch for feedback.>>
>> --
>> Thanks and Regards
>> Mahend= ra Singh Thalor
>> EnterpriseDB: http://www.enterprisedb.com



-- =
Thanks and Regards
Mahendra Singh Thalor
EnterpriseDB: http://www.enterprisedb.com=
--000000000000f866320642d380e2-- --000000000000f866330642d380e4 Content-Type: application/octet-stream; name="delta-v05-non-text-modes-for-pg_dumpall.patch" Content-Disposition: attachment; filename="delta-v05-non-text-modes-for-pg_dumpall.patch" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_mhlmof3n0 RnJvbSA0ZGViZDgzOWI1ZGJiZmQxODhhZDI0MjIxMTJmOGUzMDNjNWQ3YTcxIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBWYWliaGF2IERhbHZpIDx2YWliaGF2LmRhbHZpQGVudGVycHJp c2VkYi5jb20+CkRhdGU6IFdlZCwgNSBOb3YgMjAyNSAwNjoyMjowMCArMDAwMApTdWJqZWN0OiBb UEFUQ0ggdjEgMS8xXSBkZWx0YSB2MDUgbm9uLXRleHQgbW9kZXMgZm9yIHBnX2R1bXBhbGwKClRo aXMgZGVsdGEgcGF0Y2ggaXMgdG8gZml4IC0tcmVzdHJpY3Qta2V5CndpdGggbm9uLXRleHQgZHVt cCBmb3JtYXQuCgpWYWliaGF2IERhbHZpCi0tLQogc3JjL2Jpbi9wZ19kdW1wL3BnX2R1bXBhbGwu YyB8IDUyICsrKysrKysrKysrKystLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQogMSBmaWxlIGNoYW5n ZWQsIDE5IGluc2VydGlvbnMoKyksIDMzIGRlbGV0aW9ucygtKQoKZGlmZiAtLWdpdCBhL3NyYy9i aW4vcGdfZHVtcC9wZ19kdW1wYWxsLmMgYi9zcmMvYmluL3BnX2R1bXAvcGdfZHVtcGFsbC5jCmlu ZGV4IDYwMWI5Zjk3MzhlLi45ZTQ0N2RjOTczOCAxMDA2NDQKLS0tIGEvc3JjL2Jpbi9wZ19kdW1w L3BnX2R1bXBhbGwuYworKysgYi9zcmMvYmluL3BnX2R1bXAvcGdfZHVtcGFsbC5jCkBAIC0xMjcs NyArMTI3LDYgQEAgc3RhdGljIGNoYXIgKmZpbGVuYW1lID0gTlVMTDsKIHN0YXRpYyBTaW1wbGVT dHJpbmdMaXN0IGRhdGFiYXNlX2V4Y2x1ZGVfcGF0dGVybnMgPSB7TlVMTCwgTlVMTH07CiBzdGF0 aWMgU2ltcGxlU3RyaW5nTGlzdCBkYXRhYmFzZV9leGNsdWRlX25hbWVzID0ge05VTEwsIE5VTEx9 OwogCi1zdGF0aWMgY2hhciAqcmVzdHJpY3Rfa2V5Owogc3RhdGljIEFyY2hpdmUgKmZvdXQgPSBO VUxMOwogc3RhdGljIHBnX2NvbXByZXNzX3NwZWNpZmljYXRpb24gY29tcHJlc3Npb25fc3BlYyA9 IHswfTsKIHN0YXRpYyBpbnQgZHVtcElkVmFsID0gMDsKQEAgLTM5Nyw3ICszOTYsNyBAQCBtYWlu KGludCBhcmdjLCBjaGFyICphcmd2W10pCiAJCQkJYnJlYWs7CiAKIAkJCWNhc2UgOToKLQkJCQly ZXN0cmljdF9rZXkgPSBwZ19zdHJkdXAob3B0YXJnKTsKKwkJCQlkb3B0LnJlc3RyaWN0X2tleSA9 IHBnX3N0cmR1cChvcHRhcmcpOwogCQkJCWFwcGVuZFBRRXhwQnVmZmVyU3RyKHBnZHVtcG9wdHMs ICIgLS1yZXN0cmljdC1rZXkgIik7CiAJCQkJYXBwZW5kU2hlbGxTdHJpbmcocGdkdW1wb3B0cywg b3B0YXJnKTsKIAkJCQlicmVhazsKQEAgLTU1NSwxNSArNTU0LDIwIEBAIG1haW4oaW50IGFyZ2Ms IGNoYXIgKmFyZ3ZbXSkKIAllbHNlCiAJCU9QRiA9IHN0ZG91dDsKIAotCS8qCi0JICogSWYgeW91 IGRvbid0IHByb3ZpZGUgYSByZXN0cmljdCBrZXksIG9uZSB3aWxsIGJlIGFwcG9pbnRlZCBmb3Ig eW91LgotCSAqLwotCWlmICghcmVzdHJpY3Rfa2V5KQotCQlyZXN0cmljdF9rZXkgPSBnZW5lcmF0 ZV9yZXN0cmljdF9rZXkoKTsKLQlpZiAoIXJlc3RyaWN0X2tleSkKLQkJcGdfZmF0YWwoImNvdWxk IG5vdCBnZW5lcmF0ZSByZXN0cmljdCBrZXkiKTsKLQlpZiAoIXZhbGlkX3Jlc3RyaWN0X2tleShy ZXN0cmljdF9rZXkpKQotCQlwZ19mYXRhbCgiaW52YWxpZCByZXN0cmljdCBrZXkiKTsKKwlpZiAo YXJjaER1bXBGb3JtYXQgPT0gYXJjaE51bGwpCisJeworCQkvKgorCQkgKiBJZiB5b3UgZG9uJ3Qg cHJvdmlkZSBhIHJlc3RyaWN0IGtleSwgb25lIHdpbGwgYmUgYXBwb2ludGVkIGZvciB5b3UuCisJ CSAqLworCQlpZiAoIWRvcHQucmVzdHJpY3Rfa2V5KQorCQkJZG9wdC5yZXN0cmljdF9rZXkgPSBn ZW5lcmF0ZV9yZXN0cmljdF9rZXkoKTsKKwkJaWYgKCFkb3B0LnJlc3RyaWN0X2tleSkKKwkJCXBn X2ZhdGFsKCJjb3VsZCBub3QgZ2VuZXJhdGUgcmVzdHJpY3Qga2V5Iik7CisJCWlmICghdmFsaWRf cmVzdHJpY3Rfa2V5KGRvcHQucmVzdHJpY3Rfa2V5KSkKKwkJCXBnX2ZhdGFsKCJpbnZhbGlkIHJl c3RyaWN0IGtleSIpOworCX0KKwllbHNlIGlmIChkb3B0LnJlc3RyaWN0X2tleSkKKwkJcGdfZmF0 YWwoIm9wdGlvbiAtLXJlc3RyaWN0LWtleSBjYW4gb25seSBiZSB1c2VkIHdpdGggLS1mb3JtYXQ9 cGxhaW4iKTsKIAogCS8qCiAJICogSWYgdGhlcmUgd2FzIGEgZGF0YWJhc2Ugc3BlY2lmaWVkIG9u IHRoZSBjb21tYW5kIGxpbmUsIHVzZSB0aGF0LApAQCAtNjcwLDE1ICs2NzQsNiBAQCBtYWluKGlu dCBhcmdjLCBjaGFyICphcmd2W10pCiAKIAkJY3JlYXRlT25lQXJjaGl2ZUVudHJ5KCItLVxuLS0g UG9zdGdyZVNRTCBkYXRhYmFzZSBjbHVzdGVyIGR1bXBcbi0tXG5cbiIsICJDT01NRU5UIik7CiAK LQkJLyogY3JlYXRlIGVudHJ5IGZvciByZXN0cmljdCAqLwotCQl7Ci0JCQlQUUV4cEJ1ZmZlciBx cnkgPSBjcmVhdGVQUUV4cEJ1ZmZlcigpOwotCi0JCQlhcHBlbmRQUUV4cEJ1ZmZlcihxcnksICJc XHJlc3RyaWN0ICVzXG5cbiIsIHJlc3RyaWN0X2tleSk7Ci0JCQljcmVhdGVPbmVBcmNoaXZlRW50 cnkocXJ5LT5kYXRhLCAiUkVTVFJJQ1QiKTsKLQkJCWRlc3Ryb3lQUUV4cEJ1ZmZlcihxcnkpOwot CQl9Ci0KIAkJLyogZGVmYXVsdF90cmFuc2FjdGlvbl9yZWFkX29ubHkgPSBvZmYgKi8KIAkJewog CQkJUFFFeHBCdWZmZXIgcXJ5ID0gY3JlYXRlUFFFeHBCdWZmZXIoKTsKQEAgLTcyNyw3ICs3MjIs NyBAQCBtYWluKGludCBhcmdjLCBjaGFyICphcmd2W10pCiAJCSAqIG1ldGEtY29tbWFuZHMgc28g dGhhdCB0aGUgY2xpZW50IG1hY2hpbmUgdGhhdCBydW5zIHBzcWwgd2l0aCB0aGUgZHVtcAogCQkg KiBvdXRwdXQgcmVtYWlucyB1bmFmZmVjdGVkLgogCQkgKi8KLQkJZnByaW50ZihPUEYsICJcXHJl c3RyaWN0ICVzXG5cbiIsIHJlc3RyaWN0X2tleSk7CisJCWZwcmludGYoT1BGLCAiXFxyZXN0cmlj dCAlc1xuXG4iLCBkb3B0LnJlc3RyaWN0X2tleSk7CiAKIAkJLyoKIAkJICogV2UgdXNlZCB0byBl bWl0IFxjb25uZWN0IHBvc3RncmVzIGhlcmUsIGJ1dCB0aGF0IHNlcnZlZCBubyBwdXJwb3NlCkBA IC03OTMsMTkgKzc4OCwxMCBAQCBtYWluKGludCBhcmdjLCBjaGFyICphcmd2W10pCiAJaWYgKGFy Y2hEdW1wRm9ybWF0ID09IGFyY2hOdWxsKQogCXsKIAkJLyoKLQkJICogRXhpdCByZXN0cmljdGVk IG1vZGUganVzdCBiZWZvcmUgZHVtcGluZyB0aGUgZGF0YWJhc2VzLiAgcGdfZHVtcCB3aWxsCi0J CSAqIGhhbmRsZSBlbnRlcmluZyByZXN0cmljdGVkIG1vZGUgYWdhaW4gYXMgYXBwcm9wcmlhdGUu CisJCSAqIEV4aXQgcmVzdHJpY3RlZCBtb2RlIGp1c3QgYmVmb3JlIGR1bXBpbmcgdGhlIGRhdGFi YXNlcy4gIHBnX2R1bXAKKwkJICogd2lsbCBoYW5kbGUgZW50ZXJpbmcgcmVzdHJpY3RlZCBtb2Rl IGFnYWluIGFzIGFwcHJvcHJpYXRlLgogCQkgKi8KLQkJZnByaW50ZihPUEYsICJcXHVucmVzdHJp Y3QgJXNcblxuIiwgcmVzdHJpY3Rfa2V5KTsKLQl9Ci0JZWxzZQotCXsKLQkJLyogY3JlYXRlIGVu dHJ5IGZvciB1bnJlc3RyaWN0ICovCi0JCVBRRXhwQnVmZmVyIHFyeSA9IGNyZWF0ZVBRRXhwQnVm ZmVyKCk7Ci0KLQkJYXBwZW5kUFFFeHBCdWZmZXIocXJ5LCAiXFx1bnJlc3RyaWN0ICVzXG5cbiIs IHJlc3RyaWN0X2tleSk7Ci0JCWNyZWF0ZU9uZUFyY2hpdmVFbnRyeShxcnktPmRhdGEsICJVTlJF U1RSSUNUIik7Ci0JCWRlc3Ryb3lQUUV4cEJ1ZmZlcihxcnkpOworCQlmcHJpbnRmKE9QRiwgIlxc dW5yZXN0cmljdCAlc1xuXG4iLCBkb3B0LnJlc3RyaWN0X2tleSk7CiAJfQogCiAJaWYgKCFnbG9i YWxzX29ubHkgJiYgIXJvbGVzX29ubHkgJiYgIXRhYmxlc3BhY2VzX29ubHkpCi0tIAoyLjQzLjAK Cg== --000000000000f866330642d380e4--