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 1tzBXk-00GLIL-NO for pgsql-hackers@arkaria.postgresql.org; Mon, 31 Mar 2025 09:34:56 +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 1tzBXi-0035Ro-PI for pgsql-hackers@arkaria.postgresql.org; Mon, 31 Mar 2025 09:34:54 +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 1tzBXi-0035Rg-6e for pgsql-hackers@lists.postgresql.org; Mon, 31 Mar 2025 09:34:54 +0000 Received: from mail-qt1-x82d.google.com ([2607:f8b0:4864:20::82d]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1tzBXf-0026rX-2W for pgsql-hackers@lists.postgresql.org; Mon, 31 Mar 2025 09:34:53 +0000 Received: by mail-qt1-x82d.google.com with SMTP id d75a77b69052e-47663aeff1bso42384901cf.0 for ; Mon, 31 Mar 2025 02:34:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1743413690; x=1744018490; 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=0VT5iZiawJ9EllywaiBRAl8k9TAMhcCSPIinLptC4KA=; b=CkqMUOfmW0cy4aLjEOGRBqxmMcvQpL8VMTNDKNXPcfFo2t7z5Tmf4O8mmPGoiwlwGN tbXWc1nRKWvdGaglwTuSEFz2x/Zl37ONFG2tgBiSuEv2YTMIjeAaE82SDpwqD4k8/w32 QSj7/lyywSosK5PnITWSaxscFY/s0IrztbDXbtgsHUWm2JaRj5QwbphKE5Gx2aScGKJO gS4Zh4i3lKqbotTFzyAIwmrBulGXgpCK2iChW9AMP72ln6j5N08dM1HYXcYII+Jav11k OaC3NYIMcWq5V+z3hwC724G0/hYIDFs1tju/dHpWYmZ6plddu29NdcV/c704Nzlal9uW egTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1743413690; x=1744018490; 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=0VT5iZiawJ9EllywaiBRAl8k9TAMhcCSPIinLptC4KA=; b=ZQOb3FnlbkZoFOd6glDNx7iFqx+wbYzP5IXkE8PlJy7eKUukx7mvLTRunRbCrGW+zf lcbDPl9tQL5MSlhOq3/IhEG54BOTbZHFFJg7PVNY/8W51yzvEloQ/wj0RrVhx45Ryd09 mEIxAFB1nM4cw2ezaurUWNKZsrgYZbuKPSrauJynZSmJHSRZXhqgFqYbd47af7+/ENrc g5RRMLhYSUSvNjdIYAwjwKEC/Jtp6m1/9909ndY4DsaUbANpM6WGAML7KvQ3MFsyI3Ug wNy79s9fD0TA0ZBoRL1X84JUDaTr/Ik8grSECSay3kODQrgJEK6dEW6qaGZ6IBB4gOj3 4AFQ== X-Forwarded-Encrypted: i=1; AJvYcCV1sv6L5Zg7lHWlJ778M4DCCgcqfAetgj3DQwowIKef/iNBCzBRuiAXf38rFjOXmN3u8BEorq7gIecWe5WY@lists.postgresql.org X-Gm-Message-State: AOJu0YwW+euUj2Z6c5ZxAdT+lZFbEKOwsczF5u6uJzSBX6QLmVIMloa6 wbmrumJi1KNhnvgOO2Mr8RyQiowBtn+8yjQBMMkfiVXte0iBKf2C1lOMBf6xjcph6hlsgScJjOv 11wKqmUHuHKpQR4/PTcpXRWTZNfA= X-Gm-Gg: ASbGncumOfSAJ1cJNk2Ld707KZiZDpOgj8PrdTcvQo3AO4rbtupoV4yMc8tQBvfNgJu IT44skQYuxMJyzpfSMM2ZmZ+UjmsNePbftrtT8JWMByvzxejSy77oOYlrConhSnJLkttU6tXyq2 W3ZI1T8VFuVNhUDRuYFzeM5gkC9lU= X-Google-Smtp-Source: AGHT+IGB3B75NG0mAy6BKcjJpkVeVb3LwFk9EbIJu79DLqj4UMSdrNDe+DMQbDsL+KMbu92zwweSWxISrKdSJohoQC8= X-Received: by 2002:a05:622a:1a01:b0:475:39:9d35 with SMTP id d75a77b69052e-477ed725415mr136241901cf.14.1743413690155; Mon, 31 Mar 2025 02:34:50 -0700 (PDT) MIME-Version: 1.0 References: <202503111705.xy7fddu36qae@alvherre.pgsql> <4ef51faa-993f-46ea-9e68-7baf736c07b8@dunslane.net> <763d1c6e-9298-4bac-9bea-9331db78a154@dunslane.net> In-Reply-To: From: Mahendra Singh Thalor Date: Mon, 31 Mar 2025 15:04:38 +0530 X-Gm-Features: AQ5f1Jqi_53XGe3PQ3usj1QfENjKSa9OuSunVSgl_gHWGYV_NhKjFp4cSPaMa4s Message-ID: Subject: Re: Non-text mode for pg_dumpall To: Andrew Dunstan Cc: jian he , =?UTF-8?Q?=C3=81lvaro_Herrera?= , Srinath Reddy , pgsql-hackers@lists.postgresql.org Content-Type: multipart/mixed; boundary="000000000000b2e76a0631a0211a" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000b2e76a0631a0211a Content-Type: multipart/alternative; boundary="000000000000b2e7680631a02118" --000000000000b2e7680631a02118 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, 30 Mar 2025 at 22:20, Andrew Dunstan wrote: > > > On 2025-03-29 Sa 1:17 AM, Mahendra Singh Thalor wrote: > > On Sat, 29 Mar 2025 at 03:50, Andrew Dunstan wrote: > >> > >> On 2025-03-27 Th 5:15 PM, Andrew Dunstan wrote: > >>> On 2025-03-19 We 2:41 AM, Mahendra Singh Thalor wrote: > >>>> On Wed, 12 Mar 2025 at 21:18, Andrew Dunstan > >>>> wrote: > >>>>> On 2025-03-12 We 3:03 AM, jian he wrote: > >>>>>> On Wed, Mar 12, 2025 at 1:06=E2=80=AFAM =C3=81lvaro Herrera > >>>>>> wrote: > >>>>>>> Hello, > >>>>>>> > >>>>>>> On 2025-Mar-11, Mahendra Singh Thalor wrote: > >>>>>>> > >>>>>>>> In map.dat file, I tried to fix this issue by adding number of > >>>>>>>> characters > >>>>>>>> in dbname but as per code comments, as of now, we are not > >>>>>>>> supporting \n\r > >>>>>>>> in dbnames so i removed handling. > >>>>>>>> I will do some more study to fix this issue. > >>>>>>> Yeah, I think this is saying that you should not consider the > >>>>>>> contents > >>>>>>> of map.dat as a shell string. After all, you're not going to > >>>>>>> _execute_ > >>>>>>> that file via the shell. > >>>>>>> > >>>>>>> Maybe for map.dat you need to escape such characters somehow, so that > >>>>>>> they don't appear as literal newlines/carriage returns. > >>>>>>> > >>>>>> I am confused. > >>>>>> currently pg_dumpall plain format will abort when encountering dbname > >>>>>> containing newline. > >>>>>> the left dumped plain file does not contain all the cluster > >>>>>> databases data. > >>>>>> > >>>>>> > >>>>>> if pg_dumpall non-text format aborts earlier, > >>>>>> it's aligned with pg_dumpall plain format? > >>>>>> it's also an improvement since aborts earlier, nothing will be dumped? > >>>>>> > >>>>>> > >>>>>> am i missing something? > >>>>>> > >>>>>> > >>>>> I think we should fix that. > >>>>> > >>>>> But for the current proposal, =C3=81lvaro and I were talking this morning, > >>>>> and we thought the simplest thing here would be to have the one lin= e > >>>>> format and escape NL/CRs in the database name. > >>>>> > >>>>> > >>>>> cheers > >>>>> > >>>> Okay. As per discussions, we will keep one line entry for each > >>>> database into map.file. > >>>> > >>>> Thanks all for feedback and review. > >>>> > >>>> Here, I am attaching updated patches for review and testing. These > >>>> patches can be applied on commit a6524105d20b. > >>> > >>> > >>> I'm working through this patch set with a view to committing it. > >>> Attached is some cleanup which is where I got to today, although ther= e > >>> is more to do. One thing I am wondering is why not put the > >>> SimpleDatabaseOidList stuff in fe_utils/simle_list.{c,h} ? That's > >>> where all the similar stuff belongs, and it feels strange to have thi= s > >>> inline in pg_restore.c. (I also don't like the name much - > >>> SimpleOidStringList or maybe SimpleOidPlusStringList might be better)= . > >>> > >>> > >>> > >> > >> OK, I have done that, so here is the result. The first two are you > >> original patches. patch 3 adds the new list type to fe-utils, and patc= h > >> 4 contains my cleanups and use of the new list type. Apart from some > >> relatively minor cleanup, the one thing I would like to change is how > >> dumps are named. If we are producing tar or custom format dumps, I think > >> the file names should reflect that (oid.dmp and oid.tar rather than a > >> bare oid as the filename), and pg_restore should look for those. I'm > >> going to work on that tomorrow - I don't think it will be terribly > >> difficult. > >> > > Thanks Andrew. > > > > Here, I am attaching a delta patch for oid.tar and oid.dmp format. > > > > > OK, looks good, I have incorporated that. > > There are a couple of rough edges, though. > > First, I see this: > > > andrew@ub22arm:inst $ bin/pg_restore -C -d postgres > --exclude-database=3Dregression_dummy_seclabel > --exclude-database=3Dregression_test_extensions > --exclude-database=3Dregression_test_pg_dump dest > pg_restore: error: could not execute query: "ERROR: role "andrew" > already exists > " > Command was: " > > -- > -- Roles > -- > > CREATE ROLE andrew;" > pg_restore: warning: errors ignored on global.dat file restore: 1 > pg_restore: error: could not execute query: ERROR: database "template1" > already exists > Command was: CREATE DATABASE template1 WITH TEMPLATE =3D template0 > ENCODING =3D 'SQL_ASCII' LOCALE_PROVIDER =3D libc LOCALE =3D 'C'; > > > pg_restore: warning: errors ignored on database "template1" restore: 1 > pg_restore: error: could not execute query: ERROR: database "postgres" > already exists > Command was: CREATE DATABASE postgres WITH TEMPLATE =3D template0 ENCODIN= G > =3D 'SQL_ASCII' LOCALE_PROVIDER =3D libc LOCALE =3D 'C'; > > > pg_restore: warning: errors ignored on database "postgres" restore: 1 > pg_restore: warning: errors ignored on restore: 3 > > > > It seems pointless to be trying to create the rolw that we are connected > as, and we also expect template1 and postgres to exist. Thanks Andrew for the updated patches. Here, I am attaching a delta patch which solves the errors for the already created database and we need to reset some flags also. Please have a look over this delta patch and merge it. If we want to skip errors for connected user (CREATE ROLE username), then we need to handle it by comparing sql commands in process_global_sql_commands function or we can compare errors after executing it. delta_0002* patch is doing some handling but this is not a proper fix. I think we can merge delta_0001* and later, we can work on delta_0002. > > In a similar vein, I don't see why we are setting the --create flag in > pg_dumpall for those databases. I'm attaching a patch that is designed > to stop that, but it doesn't solve the above issues. > > I also notice a bunch of these in globals.dat: > > > -- > -- Databases > -- > > -- > -- Database "template1" dump > -- > > -- > -- Database "andrew" dump > -- > > -- > -- Database "isolation_regression_brin" dump > -- > > -- > -- Database "isolation_regression_delay_execution" dump > -- > > ... > > > The patch also tries to fix this. > > Lastly, this badly needs some TAP tests written. > > I'm going to work on reviewing the documentation next. Thank you. > > > cheers > > > andrew > > -- > Andrew Dunstan > EDB: https://www.enterprisedb.com --=20 Thanks and Regards Mahendra Singh Thalor EnterpriseDB: http://www.enterprisedb.com --000000000000b2e7680631a02118 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sun, 30 Mar 2025 at 22:20, Andrew Dunstan <andrew@dunslane.net> wrote:
><= br>>
> On 2025-03-29 Sa 1:17 AM, Mahendra Singh Thalor wrote:
&= gt; > On Sat, 29 Mar 2025 at 03:50, Andrew Dunstan <andrew@dunslane.net> wrote:
> >>> >> On 2025-03-27 Th 5:15 PM, Andrew Dunstan wrote:
> >= ;>> On 2025-03-19 We 2:41 AM, Mahendra Singh Thalor wrote:
> &g= t;>>> On Wed, 12 Mar 2025 at 21:18, Andrew Dunstan <andrew@dunslane.net>
> >>>= ;> wrote:
> >>>>> On 2025-03-12 We 3:03 AM, jian he= wrote:
> >>>>>> On Wed, Mar 12, 2025 at 1:06=E2=80= =AFAM =C3=81lvaro Herrera
> >>>>>> <alvherre@alvh.no-ip.org> wrote:
&g= t; >>>>>>> Hello,
> >>>>>>>=
> >>>>>>> On 2025-Mar-11, Mahendra Singh Thalor= wrote:
> >>>>>>>
> >>>>>&g= t;>> In map.dat file, I tried to fix this issue by adding number of> >>>>>>>> characters
> >>>>= >>>> in dbname but as per code comments, as of now, we are not<= br>> >>>>>>>> supporting \n\r
> >>&g= t;>>>>> in dbnames so i removed handling.
> >>&g= t;>>>>> I will do some more study to fix this issue.
>= >>>>>>> Yeah, I think this is saying that you should = not consider the
> >>>>>>> contents
> >= >>>>>> of map.dat as a shell string.=C2=A0 After all, you= 're not going to
> >>>>>>> _execute_
>= >>>>>>> that file via the shell.
> >>>= >>>>
> >>>>>>> Maybe for map.dat you= need to escape such characters somehow, so that
> >>>>&g= t;>> they don't appear as literal newlines/carriage returns.
&= gt; >>>>>>>
> >>>>>> I am conf= used.
> >>>>>> currently pg_dumpall plain format wi= ll abort when encountering dbname
> >>>>>> containi= ng newline.
> >>>>>> the left dumped plain file doe= s not contain all the cluster
> >>>>>> databases da= ta.
> >>>>>>
> >>>>>>
&g= t; >>>>>> if pg_dumpall non-text format aborts earlier,> >>>>>> it's aligned with pg_dumpall plain form= at?
> >>>>>> it's also an improvement since abo= rts earlier, nothing will be dumped?
> >>>>>>
&g= t; >>>>>>
> >>>>>> am i missing s= omething?
> >>>>>>
> >>>>>>=
> >>>>> I think we should fix that.
> >>&= gt;>>
> >>>>> But for the current proposal, =C3= =81lvaro and I were talking this morning,
> >>>>> and = we thought the simplest thing here would be to have the one line
> &g= t;>>>> format and escape NL/CRs in the database name.
> &= gt;>>>>
> >>>>>
> >>>>&g= t; cheers
> >>>>>
> >>>> Okay. As pe= r discussions, we will keep one line entry for each
> >>>>= ; database into map.file.
> >>>>
> >>>>= Thanks all for feedback and review.
> >>>>
> >&= gt;>> Here, I am attaching updated patches for review and testing. Th= ese
> >>>> patches can be applied on commit a6524105d20b.=
> >>>
> >>>
> >>> I'm wor= king through this patch set with a view to committing it.
> >>&= gt; Attached is some cleanup which is where I got to today, although there<= br>> >>> is more to do. One thing I am wondering is why not put= the
> >>> SimpleDatabaseOidList stuff in fe_utils/simle_lis= t.{c,h} ? That's
> >>> where all the similar stuff belon= gs, and it feels strange to have this
> >>> inline in pg_res= tore.c. (I also don't like the name much -
> >>> SimpleO= idStringList or maybe SimpleOidPlusStringList might be better).
> >= ;>>
> >>>
> >>>
> >>
>= ; >> OK, I have done that, so here is the result. The first two are y= ou
> >> original patches. patch 3 adds the new list type to fe-= utils, and patch
> >> 4 contains my cleanups and use of the new= list type. Apart from some
> >> relatively minor cleanup, the = one thing I would like to change is how
> >> dumps are named. I= f we are producing tar or custom format dumps, I think
> >> the= file names should reflect that (oid.dmp and oid.tar rather than a
> = >> bare oid as the filename), and pg_restore should look for those. I= 'm
> >> going to work on that tomorrow - I don't think = it will be terribly
> >> difficult.
> >>
> &g= t; Thanks Andrew.
> >
> > Here, I am attaching a delta pa= tch for oid.tar and oid.dmp format.
> >
>
>
> OK= , looks good, I have incorporated that.
>
> There are a couple = of rough edges, though.
>
> First, I see this:
>
><= br>> andrew@ub22arm:inst $ bin/pg_restore -C -d postgres
> --exclu= de-database=3Dregression_dummy_seclabel
> --exclude-database=3Dregres= sion_test_extensions
> --exclude-database=3Dregression_test_pg_dump d= est
> pg_restore: error: could not execute query: "ERROR: =C2=A0= role "andrew"
> already exists
> "
> Comma= nd was: "
>
> --
> -- Roles
> --
>
&g= t; CREATE ROLE andrew;"
> pg_restore: warning: errors ignored on= global.dat file restore: 1
> pg_restore: error: could not execute qu= ery: ERROR: =C2=A0database "template1"
> already exists
= > Command was: CREATE DATABASE template1 WITH TEMPLATE =3D template0
= > ENCODING =3D 'SQL_ASCII' LOCALE_PROVIDER =3D libc LOCALE =3D &= #39;C';
>
>
> pg_restore: warning: errors ignored on = database "template1" restore: 1
> pg_restore: error: could = not execute query: ERROR: =C2=A0database "postgres"
> alrea= dy exists
> Command was: CREATE DATABASE postgres WITH TEMPLATE =3D t= emplate0 ENCODING
> =3D 'SQL_ASCII' LOCALE_PROVIDER =3D libc = LOCALE =3D 'C';
>
>
> pg_restore: warning: errors= ignored on database "postgres" restore: 1
> pg_restore: wa= rning: errors ignored on restore: 3
>
>
>
> It seem= s pointless to be trying to create the rolw that we are connected
> a= s, and we also expect template1 and postgres to exist.

T= hanks Andrew for the updated patches.

Here, I am a= ttaching a delta patch which solves the errors for the already=C2=A0created= database and we need to reset some flags also. Please have a look over thi= s delta patch and merge it.

If we want to skip err= ors for connected user=C2=A0(CREATE ROLE username), then we need to handle = it by comparing sql commands=C2=A0in process_global_sql_commands function o= r we can compare errors after executing it.
delta_0002* patch is = doing some handling but this is not a proper fix.

= I think we can merge delta_0001* and later, we can work on delta_0002.

>
> In a similar vein, I don't see why we= are setting the --create flag in
> pg_dumpall for those databases. I= 'm attaching a patch that is designed
> to stop that, but it does= n't solve the above issues.
>
> I also notice a bunch of th= ese in globals.dat:
>
>
> --
> -- Databases
>= --
>
> --
> -- Database "template1" dump
&g= t; --
>
> --
> -- Database "andrew" dump
>= ; --
>
> --
> -- Database "isolation_regression_brin= " dump
> --
>
> --
> -- Database "isolati= on_regression_delay_execution" dump
> --
>
> =C2=A0 = ...
>
>
> The patch also tries to fix this.
>
&g= t; Lastly, this badly needs some TAP tests written.
>
> I'm= going to work on reviewing the documentation next.

Thank you.

>
>
> cheers
>
>
&= gt; andrew
>
> --
> Andrew Dunstan
> EDB: https://www.enterprisedb.com

<= br>--
Thanks and Regards
Mahendra Singh Thalor
EnterpriseDB: http://www.enterprisedb.com
--000000000000b2e7680631a02118-- --000000000000b2e76a0631a0211a Content-Type: application/octet-stream; name="delta_0002-pg_restore-skip-error-for-CRETE-ROLE-username.patch" Content-Disposition: attachment; filename="delta_0002-pg_restore-skip-error-for-CRETE-ROLE-username.patch" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_m8wvgktt0 RnJvbSBmNzk1YWNjZjVmZWRlMTU0NzYzMDBhNDNlYTI3MTM1NzA4YjVkMWUxIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBNYWhlbmRyYSBTaW5naCBUaGFsb3IgPG1haGk2cnVuQGdtYWls LmNvbT4KRGF0ZTogTW9uLCAzMSBNYXIgMjAyNSAxNDo1OToxMyArMDUzMApTdWJqZWN0OiBbUEFU Q0hdIHBnX3Jlc3RvcmU6IHNraXAgZXJyb3IgZm9yIENSRVRFIFJPTEUgdXNlcm5hbWUKCi0tLQog c3JjL2Jpbi9wZ19kdW1wL3BnX3Jlc3RvcmUuYyB8IDMyICsrKysrKysrKysrKysrKysrKysrKysr KysrKy0tLS0tCiAxIGZpbGUgY2hhbmdlZCwgMjcgaW5zZXJ0aW9ucygrKSwgNSBkZWxldGlvbnMo LSkKCmRpZmYgLS1naXQgYS9zcmMvYmluL3BnX2R1bXAvcGdfcmVzdG9yZS5jIGIvc3JjL2Jpbi9w Z19kdW1wL3BnX3Jlc3RvcmUuYwppbmRleCAzZDhiZTQzMjQxZC4uOGNlNWI3OTBlNTEgMTAwNjQ0 Ci0tLSBhL3NyYy9iaW4vcGdfZHVtcC9wZ19yZXN0b3JlLmMKKysrIGIvc3JjL2Jpbi9wZ19kdW1w L3BnX3Jlc3RvcmUuYwpAQCAtNjQsNyArNjQsNyBAQCBzdGF0aWMgaW50CXJlYWRfb25lX3N0YXRl bWVudChTdHJpbmdJbmZvIGluQnVmLCBGSUxFICpwZmlsZSk7CiBzdGF0aWMgaW50CXJlc3RvcmVB bGxEYXRhYmFzZXMoUEdjb25uICpjb25uLCBjb25zdCBjaGFyICpkdW1wZGlycGF0aCwKIAkJCQkJ CQkJU2ltcGxlU3RyaW5nTGlzdCBkYl9leGNsdWRlX3BhdHRlcm5zLCBSZXN0b3JlT3B0aW9ucyAq b3B0cywgaW50IG51bVdvcmtlcnMpOwogc3RhdGljIGludAlwcm9jZXNzX2dsb2JhbF9zcWxfY29t bWFuZHMoUEdjb25uICpjb25uLCBjb25zdCBjaGFyICpkdW1wZGlycGF0aCwKLQkJCQkJCQkJCQlj b25zdCBjaGFyICpvdXRmaWxlKTsKKwkJCQkJCQkJCQljb25zdCBjaGFyICpvdXRmaWxlLCBjb25z dCBjaGFyICp1c2VybmFtZSk7CiBzdGF0aWMgdm9pZCBjb3B5X29yX3ByaW50X2dsb2JhbF9maWxl KGNvbnN0IGNoYXIgKm91dGZpbGUsIEZJTEUgKnBmaWxlKTsKIHN0YXRpYyBpbnQJZ2V0X2RibmFt ZXNfbGlzdF90b19yZXN0b3JlKFBHY29ubiAqY29ubiwKIAkJCQkJCQkJCQlTaW1wbGVPaWRTdHJp bmdMaXN0ICogZGJuYW1lX29pZF9saXN0LApAQCAtNTQzLDcgKzU0Myw3IEBAIG1haW4oaW50IGFy Z2MsIGNoYXIgKiphcmd2KQogCQkJICogY29tbWFuZHMuCiAJCQkgKi8KIAkJCW5fZXJyb3JzID0g cHJvY2Vzc19nbG9iYWxfc3FsX2NvbW1hbmRzKGNvbm4sIGlucHV0RmlsZVNwZWMsCi0JCQkJCQkJ CQkJCQkgICBvcHRzLT5maWxlbmFtZSk7CisJCQkJCQkJCQkJCQkgICBvcHRzLT5maWxlbmFtZSwg b3B0cy0+Y3BhcmFtcy51c2VybmFtZSk7CiAKIAkJCWlmIChjb25uKQogCQkJCVBRZmluaXNoKGNv bm4pOwpAQCAtMTEyMyw3ICsxMTIzLDcgQEAgcmVzdG9yZUFsbERhdGFiYXNlcyhQR2Nvbm4gKmNv bm4sIGNvbnN0IGNoYXIgKmR1bXBkaXJwYXRoLAogCSAqIGZpbGUuCiAJICovCiAJaWYgKGRibmFt ZV9vaWRfbGlzdC5oZWFkID09IE5VTEwpCi0JCXJldHVybiBwcm9jZXNzX2dsb2JhbF9zcWxfY29t bWFuZHMoY29ubiwgZHVtcGRpcnBhdGgsIG9wdHMtPmZpbGVuYW1lKTsKKwkJcmV0dXJuIHByb2Nl c3NfZ2xvYmFsX3NxbF9jb21tYW5kcyhjb25uLCBkdW1wZGlycGF0aCwgb3B0cy0+ZmlsZW5hbWUs IG9wdHMtPmNwYXJhbXMudXNlcm5hbWUpOwogCiAJcGdfbG9nX2luZm8oImZvdW5kIHRvdGFsICVk IGRhdGFiYXNlIG5hbWVzIGluIG1hcC5kYXQgZmlsZSIsIG51bV90b3RhbF9kYik7CiAKQEAgLTEx NTMsNyArMTE1Myw3IEBAIHJlc3RvcmVBbGxEYXRhYmFzZXMoUEdjb25uICpjb25uLCBjb25zdCBj aGFyICpkdW1wZGlycGF0aCwKIAkJCQkJCQkJCQkJCSBkYl9leGNsdWRlX3BhdHRlcm5zKTsKIAog CS8qIE9wZW4gZ2xvYmFsLmRhdCBmaWxlIGFuZCBleGVjdXRlL2FwcGVuZCBhbGwgdGhlIGdsb2Jh bCBzcWwgY29tbWFuZHMuICovCi0Jbl9lcnJvcnNfdG90YWwgPSBwcm9jZXNzX2dsb2JhbF9zcWxf Y29tbWFuZHMoY29ubiwgZHVtcGRpcnBhdGgsIG9wdHMtPmZpbGVuYW1lKTsKKwluX2Vycm9yc190 b3RhbCA9IHByb2Nlc3NfZ2xvYmFsX3NxbF9jb21tYW5kcyhjb25uLCBkdW1wZGlycGF0aCwgb3B0 cy0+ZmlsZW5hbWUsIG9wdHMtPmNwYXJhbXMudXNlcm5hbWUpOwogCiAJLyogQ2xvc2UgdGhlIGRi IGNvbm5lY3Rpb24gYXMgd2UgYXJlIGRvbmUgd2l0aCBnbG9iYWxzIGFuZCBwYXR0ZXJucy4gKi8K IAlpZiAoY29ubikKQEAgLTEyODAsMTEgKzEyODAsMTMgQEAgcmVzdG9yZUFsbERhdGFiYXNlcyhQ R2Nvbm4gKmNvbm4sIGNvbnN0IGNoYXIgKmR1bXBkaXJwYXRoLAogICogcmV0dXJucyB0aGUgbnVt YmVyIG9mIGVycm9ycyB3aGlsZSBwcm9jZXNzaW5nIGdsb2JhbC5kYXQKICAqLwogc3RhdGljIGlu dAotcHJvY2Vzc19nbG9iYWxfc3FsX2NvbW1hbmRzKFBHY29ubiAqY29ubiwgY29uc3QgY2hhciAq ZHVtcGRpcnBhdGgsIGNvbnN0IGNoYXIgKm91dGZpbGUpCitwcm9jZXNzX2dsb2JhbF9zcWxfY29t bWFuZHMoUEdjb25uICpjb25uLCBjb25zdCBjaGFyICpkdW1wZGlycGF0aCwKKwkJY29uc3QgY2hh ciAqb3V0ZmlsZSwgY29uc3QgY2hhciAqdXNlcm5hbWUpCiB7CiAJY2hhcgkJZ2xvYmFsX2ZpbGVf cGF0aFtNQVhQR1BBVEhdOwogCVBHcmVzdWx0ICAgKnJlc3VsdDsKIAlTdHJpbmdJbmZvRGF0YSBz cWxzdGF0ZW1lbnQ7CisJU3RyaW5nSW5mb0RhdGEgcm9sZXNxbHN0YXRlbWVudDsKIAlGSUxFCSAg ICpwZmlsZTsKIAlpbnQJCQluX2Vycm9ycyA9IDA7CiAKQEAgLTEzMDgsMTAgKzEzMTAsMzAgQEAg cHJvY2Vzc19nbG9iYWxfc3FsX2NvbW1hbmRzKFBHY29ubiAqY29ubiwgY29uc3QgY2hhciAqZHVt cGRpcnBhdGgsIGNvbnN0IGNoYXIgKm8KIAogCS8qIEluaXQgc3Fsc3RhdGVtZW50IHRvIGFwcGVu ZCBjb21tYW5kcy4gKi8KIAlpbml0U3RyaW5nSW5mbygmc3Fsc3RhdGVtZW50KTsKKwlpbml0U3Ry aW5nSW5mbygmcm9sZXNxbHN0YXRlbWVudCk7CiAKIAkvKiBQcm9jZXNzIGZpbGUgdGlsbCBFT0Yg YW5kIGV4ZWN1dGUgc3FsIHN0YXRlbWVudHMuICovCiAJd2hpbGUgKHJlYWRfb25lX3N0YXRlbWVu dCgmc3Fsc3RhdGVtZW50LCBwZmlsZSkgIT0gRU9GKQogCXsKKwkJaWYgKHVzZXJuYW1lKQorCQl7 CisJCQlhcHBlbmRTdHJpbmdJbmZvU3RyaW5nKCZyb2xlc3Fsc3RhdGVtZW50LCAiXG5cbi0tXG4t LSBSb2xlc1xuLS1cblxuQ1JFQVRFIFJPTEUgIik7CisJCQlhcHBlbmRTdHJpbmdJbmZvU3RyaW5n KCZyb2xlc3Fsc3RhdGVtZW50LCB1c2VybmFtZSk7CisJCQlhcHBlbmRTdHJpbmdJbmZvU3RyaW5n KCZyb2xlc3Fsc3RhdGVtZW50LCAiOyIpOworCQl9CisKKwkJLyoKKwkJICogSWYgdGhpcyBjb21t YW5kIGlzIGZvciAiQ1JFQVRFIFJPTEUgdXNlcm5hbWUiLCB0aGVuIHNraXAgdGhpcyBhcworCQkg KiBjdXJyZW50IHVzZXIgaXMgYWxyZWFkeSBjcmVhdGVkLgorCQkgKi8KKwkJaWYgKHVzZXJuYW1l ICYmIHN0cmNtcChzcWxzdGF0ZW1lbnQuZGF0YSwgcm9sZXNxbHN0YXRlbWVudC5kYXRhKSA9PSAw KQorCQl7CisJCQlyZXNldFN0cmluZ0luZm8oJnJvbGVzcWxzdGF0ZW1lbnQpOworCQkJY29udGlu dWU7CisJCX0KKworCQlyZXNldFN0cmluZ0luZm8oJnJvbGVzcWxzdGF0ZW1lbnQpOworCiAJCXBn X2xvZ19pbmZvKCJleGVjdXRpbmcgcXVlcnk6ICVzIiwgc3Fsc3RhdGVtZW50LmRhdGEpOwogCQly ZXN1bHQgPSBQUWV4ZWMoY29ubiwgc3Fsc3RhdGVtZW50LmRhdGEpOwogCi0tIAoyLjM5LjMKCg== --000000000000b2e76a0631a0211a Content-Type: application/octet-stream; name="delta-0001-pg_restore-skip-error-if-db-already-created.patch" Content-Disposition: attachment; filename="delta-0001-pg_restore-skip-error-if-db-already-created.patch" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_m8wvgku01 RnJvbSBlYjFiZDQ4MWQ0MjE2YmIyN2RiMjI3NDEwY2M0OGVkYzRiZjI2MzRlIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBNYWhlbmRyYSBTaW5naCBUaGFsb3IgPG1haGk2cnVuQGdtYWls LmNvbT4KRGF0ZTogTW9uLCAzMSBNYXIgMjAyNSAxNDowMTo0MSArMDUzMApTdWJqZWN0OiBbUEFU Q0hdIHBnX3Jlc3RvcmU6IGlmIGRhdGFiYXNlIGlzIGFscmVhZHkgY3JlYXRlZCwgdGhlbiBzZXQg Y3JlYXRlZGIKIGFzIDAKCklmIGRhdGFiYXNlIGlzIGFscmVhZHkgY3JlYXRlZCwgdGhlbiBzZXQg Y3JlYXRlZGIgYXMgMCBzbyB0aGF0IHVzZXIKd2lsbCBub3QgZ2V0IGVycm9ycy4KCkFsc28gcmVz ZXQgc29tZSBmbGFncyBmb3IgZWFjaCBkYXRhYmFzZS4KYXMgZHVtcERhdGEsIGR1bXBTY2hlbWEs IGR1bXBTdGF0aXN0aWNzCi0tLQogc3JjL2Jpbi9wZ19kdW1wL3BnX3Jlc3RvcmUuYyB8IDM4ICsr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKwogMSBmaWxlIGNoYW5nZWQsIDM4IGlu c2VydGlvbnMoKykKCmRpZmYgLS1naXQgYS9zcmMvYmluL3BnX2R1bXAvcGdfcmVzdG9yZS5jIGIv c3JjL2Jpbi9wZ19kdW1wL3BnX3Jlc3RvcmUuYwppbmRleCBjZTcwYjdlMTJiMi4uM2Q4YmU0MzI0 MWQgMTAwNjQ0Ci0tLSBhL3NyYy9iaW4vcGdfZHVtcC9wZ19yZXN0b3JlLmMKKysrIGIvc3JjL2Jp bi9wZ19kdW1wL3BnX3Jlc3RvcmUuYwpAQCAtMTEwNyw2ICsxMTA3LDE0IEBAIHJlc3RvcmVBbGxE YXRhYmFzZXMoUEdjb25uICpjb25uLCBjb25zdCBjaGFyICpkdW1wZGlycGF0aCwKIAlpbnQJCQlu dW1fdG90YWxfZGI7CiAJaW50CQkJbl9lcnJvcnNfdG90YWw7CiAJaW50CQkJY291bnQgPSAwOwor CWNoYXIJCSpjb25uZWN0ZWRfZGIgPSBOVUxMOworCWJvb2wJCWR1bXBEYXRhID0gb3B0cy0+ZHVt cERhdGE7CisJYm9vbAkJZHVtcFNjaGVtYSA9IG9wdHMtPmR1bXBTY2hlbWE7CisJYm9vbAkJZHVt cFN0YXRpc3RpY3MgPSBvcHRzLT5kdW1wU2NoZW1hOworCisJLyogU2F2ZSBkYiBuYW1lLiAqLwor CWlmIChvcHRzLT5jcGFyYW1zLmRibmFtZSkKKwkJY29ubmVjdGVkX2RiID0gcGdfc3RyZHVwKG9w dHMtPmNwYXJhbXMuZGJuYW1lKTsKIAogCW51bV90b3RhbF9kYiA9IGdldF9kYm5hbWVfb2lkX2xp c3RfZnJvbV9tZmlsZShkdW1wZGlycGF0aCwgJmRibmFtZV9vaWRfbGlzdCk7CiAKQEAgLTEyMDks OSArMTIxNywzOSBAQCByZXN0b3JlQWxsRGF0YWJhc2VzKFBHY29ubiAqY29ubiwgY29uc3QgY2hh ciAqZHVtcGRpcnBhdGgsCiAKIAkJcGdfbG9nX2luZm8oInJlc3RvcmluZyBkYXRhYmFzZSBcIiVz XCIiLCBkYl9jZWxsLT5zdHIpOwogCisJCS8qIElmIGRhdGFiYXNlIGlzIGFscmVhZHkgY3JlYXRl ZCwgdGhlbiBkb24ndCBzZXQgY3JlYXRlREIgZmxhZy4gKi8KKwkJaWYgKG9wdHMtPmNwYXJhbXMu ZGJuYW1lKQorCQl7CisJCQljb25uID0gQ29ubmVjdERhdGFiYXNlKGRiX2NlbGwtPnN0ciwgTlVM TCwgb3B0cy0+Y3BhcmFtcy5wZ2hvc3QsCisJCQkJCW9wdHMtPmNwYXJhbXMucGdwb3J0LCBvcHRz LT5jcGFyYW1zLnVzZXJuYW1lLCBUUklfREVGQVVMVCwKKwkJCQkJZmFsc2UsIHByb2duYW1lLCBO VUxMLCBOVUxMLCBOVUxMLCBOVUxMKTsKKworCQkJaWYgKGNvbm4pCisJCQl7CisJCQkJb3B0cy0+ Y3JlYXRlREIgPSAwOworCQkJCVBRZmluaXNoKGNvbm4pOworCisJCQkJLyogVXNlIGFscmVhZHkg Y3JlYXRlZCBkYXRhYmFzZSBmb3IgY29ubmVjdGlvbi4gKi8KKwkJCQlpZiAob3B0cy0+Y3BhcmFt cy5kYm5hbWUpCisJCQkJCW9wdHMtPmNwYXJhbXMuZGJuYW1lID0gcGdfc3RyZHVwKGRiX2NlbGwt PnN0cik7CisJCQl9CisJCX0KKwogCQkvKiBSZXN0b3JlIHNpbmdsZSBkYXRhYmFzZS4gKi8KIAkJ bl9lcnJvcnMgPSByZXN0b3JlT25lRGF0YWJhc2Uoc3ViZGlycGF0aCwgb3B0cywgbnVtV29ya2Vy cywgdHJ1ZSwgY291bnQpOwogCisJCS8qIFNldCBvcHRzLT5jcmVhdGVEQiBmbGFnLiAqLworCQlp ZiAob3B0cy0+Y3JlYXRlREIgPT0gMCkKKwkJeworCQkJb3B0cy0+Y3JlYXRlREIgPSAxOworCQkJ b3B0cy0+Y3BhcmFtcy5kYm5hbWUgPSBwZ19zdHJkdXAoY29ubmVjdGVkX2RiKTsKKwkJfQorCisJ CS8qIFJlc2V0IGZsYWdzIGZvciBuZXh0IGRhdGFiYXNlLiAqLworCQlvcHRzLT5kdW1wRGF0YSA9 IGR1bXBEYXRhOworCQlvcHRzLT5kdW1wU2NoZW1hID0gZHVtcFNjaGVtYTsKKwkJb3B0cy0+ZHVt cFN0YXRpc3RpY3MgPSBkdW1wU3RhdGlzdGljczsKKwogCQkvKiBQcmludCBhIHN1bW1hcnkgb2Yg aWdub3JlZCBlcnJvcnMgZHVyaW5nIHNpbmdsZSBkYXRhYmFzZSByZXN0b3JlLiAqLwogCQlpZiAo bl9lcnJvcnMpCiAJCXsKLS0gCjIuMzkuMwoK --000000000000b2e76a0631a0211a--