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 1ewRj1-0000Ik-KK for pgadmin-hackers@arkaria.postgresql.org; Thu, 15 Mar 2018 12:11:15 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1ewRj0-00023t-Mz for pgadmin-hackers@arkaria.postgresql.org; Thu, 15 Mar 2018 12:11:14 +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 1ewRiT-0000rE-Tz for pgadmin-hackers@lists.postgresql.org; Thu, 15 Mar 2018 12:10:42 +0000 Received: from mail-oi0-x22e.google.com ([2607:f8b0:4003:c06::22e]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1ewRiH-0001wh-CA for pgadmin-hackers@postgresql.org; Thu, 15 Mar 2018 12:10:41 +0000 Received: by mail-oi0-x22e.google.com with SMTP id b8so5453918oib.11 for ; Thu, 15 Mar 2018 05:10:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=enterprisedb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=wMchq2ij/jIs8J1n+k+dYXwTWDNgGqtINQ0uC/7iJwo=; b=qYgOfoENkMGPhqpNWXk2IjSk9MiZPadLgo4wj0I/TokGHyI4bKbmFetWKo1nUHIk0N a4GNAZw8fEbuMjkoHNq4QhUgAAdMia9MAsqnbunXBW3bcJPtiIva2k8ZOS9kVFyfxxvC P4v5bhUFWc8xZddcGKYnkSM2iHfKQehHY/sv3PnDM3m3h53F18S1c573ygNCaMifyDSy 5HA070/RUAp5hKpajB8+n6v6/zcQD4FAHStuTimQuSyaUMBbl+t9zDM6FcoBDMGtHnK2 GJ/Ho48teSS8jT5VjRVd01Kb1xaeQEO8LOPdrPVJYhbn4SkLqJYjAz+mRDcdp8UtZAIU OXkA== 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=wMchq2ij/jIs8J1n+k+dYXwTWDNgGqtINQ0uC/7iJwo=; b=UYn18rnLd5oWVFfwX9R7UYRvhb3wt59QNHa6r4+H2HeslHLYMbGdM6celM78M9MJI/ f2HiN5EuIZNqyxirsrhcGLfTIe+nb6IVE/3phjVPAYjcSSbHiCIzqUdYCQ7vRNqVDKZ1 zE5gM9SfDM1p5Zxqv3K7eUdKlMFDpc2TWWEVVxJC5oWC849RBUumLWyJMcO1N6B/t6em 5HbS2sIq7JZ87sPwchixPczn5aLYRUUqJJZqQZ6wKP2Hq9SUnjb7+B0T8B15mcWs9EK7 rwKv7E3sdqlE3rEG9YetM+VS9TbzxEMXjeblLA0ph+xMOusPXKXTWr5FNfmi/iNaYO0b pdtw== X-Gm-Message-State: AElRT7HeP1uC1NmbkNZHMggjE0OGEL+kl2R7mNtbFkbJEy0hKT6OX53Q xx0ehkBK0SVN3oxRJNpV8RYIeV9xoUwf8nCkXsRAD3bJ X-Google-Smtp-Source: AG47ELsoTIYZ1q9sTRe6LFX4axvOkoTMYis0pTlOOFF98ErU2FlVgo/X5nKSQU17peXjKlTywkvczhtt6kLTtg4lLPQ= X-Received: by 10.202.82.72 with SMTP id g69mr5148754oib.83.1521115825823; Thu, 15 Mar 2018 05:10:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.203.154 with HTTP; Thu, 15 Mar 2018 05:10:25 -0700 (PDT) In-Reply-To: References: <21B515A7-C5D8-41C0-AB03-56DC2BA97F52@pgadmin.org> From: Khushboo Vashi Date: Thu, 15 Mar 2018 17:40:25 +0530 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: Dave Page Cc: pgadmin-hackers Content-Type: multipart/alternative; boundary="001a113d859875fb2e0567726001" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk --001a113d859875fb2e0567726001 Content-Type: text/plain; charset="UTF-8" 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)); > -- > Dave Page > Blog: http://pgsnake.blogspot.com > Twitter: @pgsnake > > EnterpriseDB UK: http://www.enterprisedb.com > The Enterprise PostgreSQL Company > --001a113d859875fb2e0567726001 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


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

On Tue, Mar 13, 2018 at 11:18 PM, Khushboo Vashi <= khushb= oo.vashi@enterprisedb.com> wrote:


On Wed, Mar 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@enterprisedb.com&g= t; wrote:


<= span class=3D"gmail-m_8952481264492152309m_-7872821369329844812m_5240434911= 467373297m_3546827034131714554gmail-">On Tue, Mar 13, 2018 at 9:39 AM, Dave= Page <dpage@pgadmin.org> wrote:


On 12 Mar 20= 18, at 23:12, Khushboo Vashi <khushboo.vashi@enterprisedb.com> wro= te:



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

(sqlite3.ProgrammingEr= ror) You must not use 8-bit bytestrings unless you use a text_factory that = can interpret 8-bit bytestrings (like text_factory =3D str). It is highly r= ecommended 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&#= 39;/Library/PostgreSQL/9.4/bin/pg_dump', 'ccopy_reg\n_reconstr= uctor\np0\n(cpgadmin.tools.backup\nBackupMessage\np1\nc__builtin_= _\nobject\np2\nNtp3\nRp4\n(dp5\nS\'cmd\'\np6\nV --file &q= uot;/Users/dpage/foo.dmp" --host "127.0.0.1" --port "54= 32" --username "postgres" --no-password --verbose --format= =3Dc --blobs "\xe9"\np7\nsS\'backup_type\'\np8\nI3\n= sS\'database\'\np9\nV\xe9\np10\nsS\'bfile\'\np11\nS\'foo.dmp\'\np12\nsS\'sid\'\np13\nI1\nsb.', u= 9;--file,/Users/dpage/foo.dmp,--host,127.0.0.1,--port,5432,--user= name,postgres,--no-password,--verbose,--format=3Dc,--blobs,\xe9&#= 39;, '/var/lib/pgadmin/sessions/process_logs/180312205250107339= 9;, None, None, None, None)]

Any thoughts as t= o 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.
<= div class=3D"gmail-m_8952481264492152309m_-7872821369329844812m_52404349114= 67373297m_3546827034131714554gmail-m_6187657306916305888m_35719401381814875= 61HOEnZb">

Deleting all the records from the process table from SQLITE will s= olve this problem.
There were few issues related to encoding-deco= ding in my old patches, you may have applied those.
=

I deleted the database entire= ly, 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 issue but not now.
P= lease 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.

We= ll I eventually got this to work (basically recreated most of my dev enviro= nment), so I committed the patch as it's clearly an improvement.
<= div>
Thanks.=C2=A0
I can still reproduce the display issue= I mentioned though - see the attached screenshot which shows &#233; 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 characte= rs in the string?

= I have tested it with a single character also but couldn't reproduce th= is. Please find the attached screen-shot for the same.=C2=A0
Can = you please take a complete screen shot of the screen (with left side tree a= nd properties 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(_.une= scape(self.detailed_desc));


--001a113d859875fb2e0567726001--