Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1ewZ0e-0003j5-P0 for pgadmin-hackers@arkaria.postgresql.org; Thu, 15 Mar 2018 19:57:56 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1ewZ0c-0007lu-5u for pgadmin-hackers@arkaria.postgresql.org; Thu, 15 Mar 2018 19:57:54 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1ewZ0b-0007lk-VU for pgadmin-hackers@lists.postgresql.org; Thu, 15 Mar 2018 19:57:54 +0000 Received: from mail-wm0-x229.google.com ([2a00:1450:400c:c09::229]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1ewZ0X-0003sf-Qs for pgadmin-hackers@postgresql.org; Thu, 15 Mar 2018 19:57:53 +0000 Received: by mail-wm0-x229.google.com with SMTP id t6so12829208wmt.5 for ; Thu, 15 Mar 2018 12:57:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pgadmin-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=F4+BLTXljoHEqPSRGZUlyfiOLZKwF0zC1yQ1axfkmXg=; b=xo5AcpqPiMoN88JvPnlI/svVmyg+o9Awa2+Ni/V03Sc03jQ4IX8Oh+Sszk6tx3lFhE qyFLOsMYEFpjXwSSWs/w3kfGyd2UfNfuOcDlORMXMKUaEmhxMpdVRoBXtCowQJdJa3eN gUuIN3LSeOXIVfzR//NvZrgppOnzNa+wtR3j9zwc2duSWZEEml1d/KAk6CQq2mH/39bS G74OAJqjkUDJZAonezns5cltYMse8OkfQuMdxUZQVVTUd8fYoCv5PM68gPJgcsf7TS+T rAUt5CG1PtsXY+2TOzJwQupnd+rBhoP6W9mZkpuqSZ7ojFfs4nmu/xHIcvF/1vukLBb2 FkTw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=F4+BLTXljoHEqPSRGZUlyfiOLZKwF0zC1yQ1axfkmXg=; b=iDAwHzHw7GdOCXoCpS02sdaiFM77LETBz++2jJnGgkx56HUXnCbh9yXxURXRMtaBAp oDrVFf9NcJuE4/hsi0YNXaVG+gKGFS3jOlfHbs0hd9nVwcNlkYzJRS1b7oeIllfZChYY sDpWY7uNTaJmStruv7V+misbGlEmaFSB5CNinpvgvBhgmkfCX8l5JzGIzgnTIPNj6SZi DmjrXZpDtX8+0125J3SHKZ4HsA2FXGhuwzAzkwsetriRjPWrjG9PJl5CHZkK42DcWW7v IF6Qh5gBSMtjSO1uXLyPkDGBcVVeFR4vgbO/aUc8Y0R4RCSdX/Lfswgcd0513h1LzeOM lWAw== X-Gm-Message-State: AElRT7He6hjmox9LBvf+Cf7RKwVKoHT1ISA4JHzFcTM5c93uF5Qz3itv GqKy2EFh+2pwrPWPGRsH02pdB8v96fbfMaqdTy8HAA== X-Google-Smtp-Source: AG47ELspqtTeLCIBuyBEGKLqv4xRSSmTvlPLYLvtbcxUyCZky3kgRbq9YG2CluUJFpad6xduLHI/d3EwDPwf0dWEUJI= X-Received: by 10.28.190.18 with SMTP id o18mr6016596wmf.86.1521143867121; Thu, 15 Mar 2018 12:57:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.109.7 with HTTP; Thu, 15 Mar 2018 12:57:46 -0700 (PDT) In-Reply-To: References: <21B515A7-C5D8-41C0-AB03-56DC2BA97F52@pgadmin.org> From: Dave Page Date: Thu, 15 Mar 2018 15:57:46 -0400 Message-ID: Subject: =?UTF-8?Q?Re=3A_=5BpgAdmin4=5D=5BPatch=5D=3A_RM_=232963_=2D_Backup_database=2C_R?= =?UTF-8?Q?estore_database_and_Maintenance_Database_failed_for_=C3=A9_objec?= =?UTF-8?Q?t=2E?= To: Khushboo Vashi Cc: pgadmin-hackers Content-Type: multipart/alternative; boundary="f403043c3bf0da3d40056778e7ed" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk --f403043c3bf0da3d40056778e7ed Content-Type: text/plain; charset="UTF-8" Hi On Thu, Mar 15, 2018 at 8:10 AM, Khushboo Vashi < khushboo.vashi@enterprisedb.com> wrote: > > > On Thu, Mar 15, 2018 at 3:13 AM, Dave Page wrote: > >> Hi >> >> On Tue, Mar 13, 2018 at 11:18 PM, Khushboo Vashi < >> khushboo.vashi@enterprisedb.com> wrote: >> >>> >>> >>> On Wed, Mar 14, 2018 at 2:18 AM, Dave Page wrote: >>> >>>> >>>> >>>> On Tue, Mar 13, 2018 at 12:46 AM, Khushboo Vashi < >>>> khushboo.vashi@enterprisedb.com> wrote: >>>> >>>>> >>>>> >>>>> On Tue, Mar 13, 2018 at 9:39 AM, Dave Page wrote: >>>>> >>>>>> >>>>>> >>>>>> On 12 Mar 2018, at 23:12, Khushboo Vashi < >>>>>> khushboo.vashi@enterprisedb.com> wrote: >>>>>> >>>>>> >>>>>> >>>>>> On Tue, Mar 13, 2018 at 2:29 AM, Dave Page wrote: >>>>>> >>>>>>> So I was trying to test this, and every time I try to run a backup, >>>>>>> I'm getting the following, with or without your patch: >>>>>>> >>>>>>> (sqlite3.ProgrammingError) You must not use 8-bit bytestrings unless >>>>>>> you use a text_factory that can interpret 8-bit bytestrings (like >>>>>>> text_factory = str). It is highly recommended that you instead just switch >>>>>>> your application to Unicode strings. [SQL: u'INSERT INTO process (pid, >>>>>>> user_id, command, "desc", arguments, logdir, start_time, end_time, >>>>>>> exit_code, acknowledge) VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?)'] >>>>>>> [parameters: (180312205250107339, 1, u'/Library/PostgreSQL/9.4/bin/pg_dump', >>>>>>> 'ccopy_reg\n_reconstructor\np0\n(cpgadmin.tools.backup\nBack >>>>>>> upMessage\np1\nc__builtin__\nobject\np2\nNtp3\nRp4\n(dp5\nS\'cmd\'\np6\nV >>>>>>> --file "/Users/dpage/foo.dmp" --host "127.0.0.1" --port "5432" --username >>>>>>> "postgres" --no-password --verbose --format=c --blobs >>>>>>> "\xe9"\np7\nsS\'backup_type\'\np8\nI3\nsS\'database\'\np9\nV >>>>>>> \xe9\np10\nsS\'bfile\'\np11\nS\'foo.dmp\'\np12\nsS\'sid\'\np13\nI1\nsb.', >>>>>>> u'--file,/Users/dpage/foo.dmp,--host,127.0.0.1,--port,5432,- >>>>>>> -username,postgres,--no-password,--verbose,--format=c,--blobs,\xe9', >>>>>>> '/var/lib/pgadmin/sessions/process_logs/180312205250107339', None, >>>>>>> None, None, None)] >>>>>>> >>>>>>> Any thoughts as to what's going on? I wasn't getting this on my >>>>>>> other laptop, and I can't think what else we would have changed to cause >>>>>>> this. >>>>>>> >>>>>>> Deleting all the records from the process table from SQLITE will >>>>>> solve this problem. >>>>>> There were few issues related to encoding-decoding in my old patches, >>>>>> you may have applied those. >>>>>> >>>>>> >>>>>> I deleted the database entirely, and still saw the problem. >>>>>> >>>>>> I have tried many things to reproduce this but couldn't. I faced >>>>> this issue when I was fixing the issue but not now. >>>>> Please make sure to delete the old session and a process table (or >>>>> database) and apply my latest patch. (of course you do this :) ) >>>>> I have PY - 2.7.12, psycopg2 - 2.7.4 and SQLAlhemy -1.0.14 to be more >>>>> specific. >>>>> >>>>>> >>>> Well I eventually got this to work (basically recreated most of my dev >>>> environment), so I committed the patch as it's clearly an improvement. >>>> >>>> Thanks. >>> >>>> I can still reproduce the display issue I mentioned though - see the >>>> attached screenshot which shows é in a couple of places. I wonder if >>>> it's because the database name is just a single character in my tests, >>>> whilst you had some other unicode characters in the string? >>>> >>>> I have tested it with a single character also but couldn't reproduce >>> this. Please find the attached screen-shot for the same. >>> Can you please take a complete screen shot of the screen (with left side >>> tree and properties panel of the database) and send it? >>> >> >> Sure - attached. >> >> > I didn't find any root cause as the below line responsible for un-escaping > the html and it is clearly shown that it is not happening in your case. > $header.find('.bg-detailed-desc').html(_.unescape(self.detailed_desc)); > Well this is weird - I just tried it again with the dev tools enabled (to look for console errors), and it worked. Tried again without the dev tools, and it's still working. I have no idea what was going on, but it's working now. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company --f403043c3bf0da3d40056778e7ed Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi

On Thu, Mar 15, 2018 at 8:10 AM, Khushboo Vashi <= ;khush= boo.vashi@enterprisedb.com> wrote:


On Thu, Mar 15, 2018 at 3:13 AM, Dave Page <d= page@pgadmin.org> wrote:
Hi

On Tue, Mar 13, 2018 at 11:18 PM, Khushboo Vas= hi <khushboo.vashi@enterprisedb.com> wrot= e:

On Wed, M= ar 14, 2018 at 2:18 AM, Dave Page <dpage@pgadmin.org> wrote:=

=

On Tue, Mar= 13, 2018 at 12:46 AM, Khushboo Vashi <khushboo.vashi@enterp= risedb.com> wrote:


On Tue, Mar 13, 2018 at 9:39 AM, Dave Page <dpage@pgadmin.org>= wrote:


On 12 Mar 2018, at 23:12, Khushboo Vashi <= khushb= oo.vashi@enterprisedb.com> wrote:



On Tue, Mar 13, 2018 at 2:29 AM, Dave Page <dpage@pgadm= in.org> wrote:
So I was trying to test this, and every time I try = to run a backup, I'm getting the following, with or without your patch:=

(sqlite3.ProgrammingError) You must not use 8-bit bytes= trings unless you use a text_factory that can interpret 8-bit bytestrings (= like text_factory =3D str). It is highly recommended that you instead just = switch your application to Unicode strings. [SQL: u'INSERT INTO process= (pid, user_id, command, "desc", arguments, logdir, start_time, e= nd_time, exit_code, acknowledge) VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?)'= ] [parameters: (180312205250107339, 1, u'/Library/PostgreSQL/9.4/bin/pg_dump', 'ccopy_reg\n_reconstructor\np0\n(cpgadmin.tools.b= ackup\nBackupMessage\np1\nc__builtin__\nobject\np2\nNtp3\nRp4\n(d= p5\nS\'cmd\'\np6\nV --file "/Users/dpage/foo.dmp" --= host "127.0.0.1" --port "5432" --username "postgre= s" --no-password --verbose --format=3Dc --blobs "\xe9"\np7\n= sS\'backup_type\'\np8\nI3\nsS\'database\'\np9\nV\= xe9\np10\nsS\'bfile\'\np11\nS\'foo.dmp\'\np12\nsS\'= ;sid\'\np13\nI1\nsb.', u'--file,/Users/dpage/foo.dmp,= --host,127.0.0.1,--port,5432,--username,postgres,--no-password,--= verbose,--format=3Dc,--blobs,\xe9', '/var/lib/pgadmin/sessions= /process_logs/180312205250107339', None, None, None, None)]

Any thoughts as to what's going on? I wasn't= getting this on my other laptop, and I can't think what else we would = have changed to cause this.

Deleting all the records from the process table from SQLITE= will solve this problem.
There were few issues related to encodi= ng-decoding in my old patches, you may have applied those.

I deleted the database= entirely, and still saw the problem.

I have tried many things to reproduce= this but couldn't.=C2=A0 I faced this issue when I was fixing the issu= e but not now.
Please make sure to delete the old session and a p= rocess table (or database) and apply my latest patch. (of course you do thi= s :) )
I have PY - 2.7.12, psycopg2 - 2.7.4 and SQLAlhemy -1.0.14= to be more specific.

Well I ev= entually got this to work (basically recreated most of my dev environment),= so I committed the patch as it's clearly an improvement.
Thanks.=C2=A0
I can still reproduce the display issue I ment= ioned though - see the attached screenshot which shows &#233; in a coup= le of places. I wonder if it's because the database name is just a sing= le character in my tests, whilst you had some other unicode characters in t= he string?

I have = tested it with a single character also but couldn't reproduce this. Ple= ase find the attached screen-shot for the same.=C2=A0
Can you ple= ase take a complete screen shot of the screen (with left side tree and prop= erties panel of the database) and send it?

Sure - attached.=C2=A0

=C2=A0
= I didn't find any root cause as the below line responsible for un-escap= ing the html and it is clearly shown that it is not happening in your case.= =C2=A0
$header.f= ind('.bg-detailed-desc').html(_= .unescape(self.detailed_desc));
<= /blockquote>

Well this is weird - I just tried it again = with the dev tools enabled (to look for console errors), and it worked. Tri= ed again without the dev tools, and it's still working.

<= /div>
I have no idea what was going on, but it's working now.=C2=A0=

--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgs= nake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Co= mpany
--f403043c3bf0da3d40056778e7ed--