Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bMp5o-00030z-HU for pgadmin-hackers@arkaria.postgresql.org; Tue, 12 Jul 2016 04:14:44 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1bMp5n-0000Td-Gy for pgadmin-hackers@arkaria.postgresql.org; Tue, 12 Jul 2016 04:14:43 +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.84_2) (envelope-from ) id 1bMp5Z-0000Fq-1r for pgadmin-hackers@postgresql.org; Tue, 12 Jul 2016 04:14:29 +0000 Received: from mail-lf0-x22b.google.com ([2a00:1450:4010:c07::22b]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84_2) (envelope-from ) id 1bMp5O-0006pY-Gh for pgadmin-hackers@postgresql.org; Tue, 12 Jul 2016 04:14:27 +0000 Received: by mail-lf0-x22b.google.com with SMTP id b199so2552089lfe.0 for ; Mon, 11 Jul 2016 21:14:18 -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=b0u9iSWSSPxstc92PMwl+bStDW2SEEEkgd3nRcQAtwg=; b=z/Sd1Lj8wUqvY7ncnUD9XDxafbNQLbgaeEeVwN/E7qiNVS66ZoV2tDT1seV9EQFc4M TOvKUec7QvIeO4ovEQKY8HU9nEmEtc5MfVXUFvuHhw5f0NYYiy7dUQduLmZiLS0c2e1b 1iETH7kORVmD/LPxE6I48CzWRScyp/b5r5smbxFSL7qOPgblYTVG3Qjw7DLaH2LHtGSO lR58YfrmMxBj0IubLSm9itpQ1C4VpqkQ7/DpGiP5dh0HdGuWlBb9r8XtHMHSUOYLGP5S z4rmEXi5OzY809Ukzxz5kZCPTHQ4WiPOBkxHJlsVpuiLw3fK7WDfnrGU/HKdQvEEhru1 BW/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=b0u9iSWSSPxstc92PMwl+bStDW2SEEEkgd3nRcQAtwg=; b=F/dNZbVopahs7WPmPe9PL4rub1jSFk6nEoRHzcZhibXlcLfrVhNmh2GnJ3gBcnKPKq Yht2/NsxfeE78tCCyQ9/Cd23mMXAV7NrzBKyJODNbiO3gzF0T4RvBgMMvTezmwNdjQjb dq/MMAnPlFsCpil2A73e8qB3TgOFRKQP8Z57mmtAeFt02MTcn9vRklMvSTaD/XituuMr 17N7J+3KTKRdwOl9lcvcuOPAtxthgR+EWpXgf/HkH6ELhyLe9LJDr6UUuoCipn5F205v dwZRafoGlLszE4BNzOMWsgqCfnSRZiOaFzy54bBCrQ2VqkJZoNw+gZUgUfpy6B3mwGkf 86uw== X-Gm-Message-State: ALyK8tLNtzHqnLgovJe5WsGdqySpvKDYLsYhKOaGAca6EuaAmBP8omTOVJ7Mi1BP7nJp3DGvCSC6uZC6OvymZsjU X-Received: by 10.46.9.22 with SMTP id 22mr33659ljj.63.1468296857518; Mon, 11 Jul 2016 21:14:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.157.205 with HTTP; Mon, 11 Jul 2016 21:14:16 -0700 (PDT) In-Reply-To: References: <1C830532-F2F0-4FBC-BD17-4428CE9AA53D@pgadmin.org> From: Khushboo Vashi Date: Tue, 12 Jul 2016 09:44:16 +0530 Message-ID: Subject: Re: pgAdmin IV API test cases patch To: Priyanka Shendge Cc: Dave Page , pgadmin-hackers , Kanchan Mohitey Content-Type: multipart/alternative; boundary=001a114b18ba9e180e05376880d4 X-Pg-Spam-Score: -2.6 (--) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgadmin-hackers Precedence: bulk Sender: pgadmin-hackers-owner@postgresql.org --001a114b18ba9e180e05376880d4 Content-Type: text/plain; charset=UTF-8 On Mon, Jul 11, 2016 at 7:15 PM, Priyanka Shendge < priyanka.shendge@enterprisedb.com> wrote: > > > On 11 July 2016 at 18:35, Dave Page wrote: > >> On Mon, Jul 11, 2016 at 1:25 PM, Priyanka Shendge >> wrote: >> > Sorry, by mistake i copied incomplete query. There is an OID present >> for >> > added database. >> > >> > SELECT >> > db.oid as did, db.datname, db.datallowconn, >> > pg_encoding_to_char(db.encoding) AS serverencoding, >> > has_database_privilege(db.oid, 'CREATE') as cancreate, datlastsysoid >> > FROM >> > pg_database db >> > WHERE db.oid = 158579 >> >> There's nothing wrong with that query. Can you work with Khushboo to >> see if she can reproduce or help figure it out please? >> > > I had work with Khushboo, she also tried to reproduce the issue at her > it's working fine for her. > Khushboo also tried to troubleshoot/trace the issue but not able to figure > out where exactly its failing; > as issue was not reproducible. > > @Khushboo: > Please add if i am missing anything. > >> >> We have tried to reproduce this issue at our end several times with the different scenarios but every attempt was unsuccessful. Here the newly created database connection is failing which should not as the database is created properly as per the log. The above query (mentioned by Priyanka) executes from the psycopg2 driver and could fail in 2 scenarios, either the database has been dropped before this particular test-case runs or the database is not created properly through the 'create database test-case'. But as per the log, the 'delete database test-case' runs after this test-case and the database is created properly. Can any privilege issue prevent the database connection in this scenario? Thanks, Khushboo > Thanks. >> >> > On 11 July 2016 at 17:18, Dave Page wrote: >> >> >> >> Hi, >> >> >> >> No, sorry I don't have an extra system you can test on. >> >> >> >> It's pretty clear that query would fail - it's missing a database OID >> >> after the = >> >> >> >> On Fri, Jul 8, 2016 at 10:38 AM, Priyanka Shendge >> >> wrote: >> >> > Hi Dave, >> >> > >> >> > I have tried to reproduce the issue by running the test-suite on >> >> > different >> >> > machines (64 and 32 bit) and >> >> > users on PG9.4/9.5 (Provided different "test_db_username" in >> >> > test_config.json). It is working fine at my end. >> >> > >> >> > The log file (output.log) sent by you shows following query is >> failing >> >> > at >> >> > your end: >> >> > >> >> > SELECT >> >> > db.oid as did, db.datname, db.datallowconn, >> >> > pg_encoding_to_char(db.encoding) AS serverencoding, >> >> > has_database_privilege(db.oid, 'CREATE') as cancreate, >> datlastsysoid >> >> > FROM >> >> > pg_database db >> >> > WHERE db.oid = >> >> > >> >> > Let me know if you have an extra system where I can reproduce the >> issue. >> >> > >> >> > >> >> > On 5 July 2016 at 15:40, Dave Page wrote: >> >> >> >> >> >> Attached. >> >> >> >> >> >> On Tue, Jul 5, 2016 at 9:00 AM, Priyanka Shendge >> >> >> wrote: >> >> >> > Hi Dave, >> >> >> > >> >> >> > I tried running the testsuite against PG9.4 and unable to >> reproduce >> >> >> > the >> >> >> > failures. >> >> >> > I have added debug statements to previous patch. Patch attached. >> >> >> > Could you please re-run the same and send me the logs and output? >> >> >> > >> >> >> > Thank you. >> >> >> > >> >> >> > On 4 July 2016 at 17:30, Dave Page wrote: >> >> >> >> >> >> >> >> Hi >> >> >> >> >> >> >> >> The test data was the default, and I ran against PG 9.4. All >> other >> >> >> >> logs >> >> >> >> were attached to my previous email. >> >> >> >> >> >> >> >> -- >> >> >> >> Dave Page >> >> >> >> Blog: http://pgsnake.blogspot.com >> >> >> >> Twitter: @pgsnake >> >> >> >> >> >> >> >> EnterpriseDB UK:http://www.enterprisedb.com >> >> >> >> The Enterprise PostgreSQL Company >> >> >> >> >> >> >> >> On 4 Jul 2016, at 12:16, Priyanka Shendge >> >> >> >> wrote: >> >> >> >> >> >> >> >> Hi Dave, >> >> >> >> >> >> >> >> I am unable to reproduce issue on my side; tried on Python 2.7 >> and >> >> >> >> Python >> >> >> >> 3.4. >> >> >> >> Could you please provide me DEBUG logs and test data using for >> >> >> >> database >> >> >> >> node? >> >> >> >> >> >> >> >> Thank you. >> >> >> >> >> >> >> >> On 30 June 2016 at 00:51, Dave Page wrote: >> >> >> >>> >> >> >> >>> Hi, >> >> >> >>> >> >> >> >>> That's better. I tweaked a few things and fixed a bug related to >> >> >> >>> recent changes to the schema version config. Patch attached. >> >> >> >>> >> >> >> >>> However, there are still issues: >> >> >> >>> >> >> >> >>> 1) The testsuite doesn't run to completion. See the attached >> >> >> >>> stdout.txt and logger.txt files. >> >> >> >>> 2) stdout should only display the test summary - what tests are >> >> >> >>> currently running (and pass/fail), and a summary at the end - >> even >> >> >> >>> if >> >> >> >>> there's a crash like I saw. >> >> >> >>> 3) The output log file should contain the full output, including >> >> >> >>> what's sent to stdout. >> >> >> >>> 4) The output advises the user to check >> >> >> >>> ".../pgadmin4/web/regression". >> >> >> >>> This should be in the summary at the end, and should be >> corrected >> >> >> >>> to >> >> >> >>> show the correct (full) path. >> >> >> >>> >> >> >> >>> Thanks. >> >> >> >>> >> >> >> >>> >> >> >> >>> On Wed, Jun 29, 2016 at 2:52 PM, Priyanka Shendge >> >> >> >>> wrote: >> >> >> >>> > Hi Dave, >> >> >> >>> > >> >> >> >>> > As per discussion over mail i have created separate config >> files >> >> >> >>> > for >> >> >> >>> > credentials and test data. >> >> >> >>> > >> >> >> >>> > PFA patch for same. Kindly, review and let me know for >> >> >> >>> > modifications. >> >> >> >>> > >> >> >> >>> > On 27 June 2016 at 15:10, Priyanka Shendge >> >> >> >>> > wrote: >> >> >> >>> >> >> >> >> >>> >> >> >> >> >>> >> >> >> >> >>> >> On 27 June 2016 at 13:24, Dave Page >> wrote: >> >> >> >>> >>> >> >> >> >>> >>> On Sun, Jun 26, 2016 at 12:05 PM, Priyanka Shendge >> >> >> >>> >>> wrote: >> >> >> >>> >>> > >> >> >> >>> >>> > >> >> >> >>> >>> > On 24 June 2016 at 16:17, Dave Page >> >> >> >>> >>> > wrote: >> >> >> >>> >>> >> >> >> >> >>> >>> >> Hi >> >> >> >>> >>> >> >> >> >> >>> >>> >> On Thu, Jun 23, 2016 at 2:41 PM, Priyanka Shendge >> >> >> >>> >>> >> wrote: >> >> >> >>> >>> >> > >> >> >> >>> >>> >> > >> >> >> >>> >>> >> > On 15 June 2016 at 15:05, Priyanka Shendge >> >> >> >>> >>> >> > wrote: >> >> >> >>> >>> >> >> >> >> >> >>> >>> >> >> Thanks a lot Dave. >> >> >> >>> >>> >> >> >> >> >> >>> >>> >> >> On 15 June 2016 at 14:09, Dave Page < >> dpage@pgadmin.org> >> >> >> >>> >>> >> >> wrote: >> >> >> >>> >>> >> >>> >> >> >> >>> >>> >> >>> Hi >> >> >> >>> >>> >> >>> >> >> >> >>> >>> >> >>> On Thu, Jun 9, 2016 at 1:37 PM, Priyanka Shendge >> >> >> >>> >>> >> >>> wrote: >> >> >> >>> >>> >> >>> > Hi Dave, >> >> >> >>> >>> >> >>> > >> >> >> >>> >>> >> >>> > PFA updated patch. I have made changes suggested by >> >> >> >>> >>> >> >>> > you. >> >> >> >>> >>> >> >>> > >> >> >> >>> >>> >> >>> > Kindly, review and let me know for more changes. >> >> >> >>> >>> >> >>> >> >> >> >>> >>> >> >>> OK, I got a bit further this time, but not there yet. >> >> >> >>> >>> >> >>> >> >> >> >>> >>> >> >>> 1) The patch overwrote my test_config.json file. That >> >> >> >>> >>> >> >>> should >> >> >> >>> >>> >> >>> never >> >> >> >>> >>> >> >>> happen (that file shouldn't be in the source tree). >> >> >> >>> >>> >> >>> test_config.json.in should be the file that's >> included >> >> >> >>> >>> >> >>> in >> >> >> >>> >>> >> >>> the >> >> >> >>> >>> >> >>> patch. >> >> >> >>> >>> >> >> >> >> >> >>> >>> >> >> >> >> >> >>> >>> >> >> OK. >> >> >> >>> >>> >> >>> >> >> >> >>> >>> >> >>> >> >> >> >>> >>> >> >>> 2) The updated test_config.json file is huge. >> >> >> >>> >>> >> > >> >> >> >>> >>> >> > >> >> >> >>> >>> >> > Current configuration file >> web/regression/test_config.json >> >> >> >>> >>> >> > contains >> >> >> >>> >>> >> > test >> >> >> >>> >>> >> > data(credentials) for each tree node; >> >> >> >>> >>> >> > which is used while adding and updating the respective >> >> >> >>> >>> >> > node. >> >> >> >>> >>> >> >> >> >> >>> >>> >> Why would we need that? >> >> >> >>> >>> > >> >> >> >>> >>> > >> >> >> >>> >>> > Each node file (e.g. test_db_add.py and test_db_put.py) >> uses >> >> >> >>> >>> > respective >> >> >> >>> >>> > credentials test data from >> >> >> >>> >>> > test_config.json while execution. >> >> >> >>> >>> >> >> >> >>> >>> That doesn't answer my question - why do we need separate >> >> >> >>> >>> credentials >> >> >> >>> >>> for each node? >> >> >> >>> >> >> >> >> >>> >> >> >> >> >>> >> Sorry for typo, its test data not credentials. >> >> >> >>> >> >> >> >> >>> >>> >> >> >> >>> >>> >> >> >> >>> >>> >> We should have just one set of credentials for >> >> >> >>> >>> >> everything. >> >> >> >>> >>> > >> >> >> >>> >>> > >> >> >> >>> >>> > Let me know if my understanding is clear: >> >> >> >>> >>> > >> >> >> >>> >>> > Should i keep basic credentials of each node (database, >> >> >> >>> >>> > schema) >> >> >> >>> >>> > into >> >> >> >>> >>> > test_config.json >> >> >> >>> >>> > instead taking care of each field? >> >> >> >>> >>> >> >> >> >>> >>> You should have one set of credentials that's used for the >> >> >> >>> >>> entire >> >> >> >>> >>> test >> >> >> >>> >>> run. >> >> >> >>> >> >> >> >> >>> >> >> >> >> >>> >> Sure. I'll separate the credentials and test data into 2 >> >> >> >>> >> different >> >> >> >>> >> files. >> >> >> >>> >> So, a normal user can run the tests into one go after some >> minor >> >> >> >>> >> credentials changes. >> >> >> >>> >> And an advanced user can have an option to change the test >> data >> >> >> >>> >> if >> >> >> >>> >> he >> >> >> >>> >> wants. >> >> >> >>> >>> >> >> >> >>> >>> >> >> >> >>> >>> >> >>> I should only need to >> >> >> >>> >>> >> >>> define one or more connections, then be able to run >> the >> >> >> >>> >>> >> >>> tests. >> >> >> >>> >>> >> >>> If >> >> >> >>> >>> >> >>> you >> >> >> >>> >>> >> >>> need to keep configuration info for "advanced users", >> >> >> >>> >>> >> >>> let's >> >> >> >>> >>> >> >>> put it >> >> >> >>> >>> >> >>> in >> >> >> >>> >>> >> >>> a different file to avoid confusing/scaring everyone >> >> >> >>> >>> >> >>> else. >> >> >> >>> >>> >> >>> Maybe >> >> >> >>> >>> >> >>> split >> >> >> >>> >>> >> >>> it into config.json for the stuff the user needs to >> edit >> >> >> >>> >>> >> >>> (config.json.in would go in git), and >> test_config.json >> >> >> >>> >>> >> >>> for >> >> >> >>> >>> >> >>> the >> >> >> >>> >>> >> >>> test >> >> >> >>> >>> >> >>> configuration. >> >> >> >>> >>> >> > >> >> >> >>> >>> >> > >> >> >> >>> >>> >> > Should i keep login and server credentials into >> >> >> >>> >>> >> > web/regression/test_config.json file and >> >> >> >>> >>> >> > put respective node details into config.json file of >> >> >> >>> >>> >> > respective >> >> >> >>> >>> >> > node's >> >> >> >>> >>> >> > tests >> >> >> >>> >>> >> > directory? >> >> >> >>> >>> >> >> >> >> >>> >>> >> Not if you expect users to need to edit them - and if >> not, >> >> >> >>> >>> >> why >> >> >> >>> >>> >> are >> >> >> >>> >>> >> the >> >> >> >>> >>> >> values not just hard-coded? >> >> >> >>> >>> >> >> >> >> >>> >>> >> > e.g. for database node: >> >> >> >>> >>> >> > I'll create config.json file into .../databases/tests/ >> >> >> >>> >>> >> > directory >> >> >> >>> >>> >> > put database add and update credentials into >> config.json >> >> >> >>> >>> >> >> >> >> >>> >>> >> The key here is to make it simple for users. >> >> >> >>> >>> >> >> >> >> >>> >>> >> - To run the default tests, they should be able to >> copy/edit >> >> >> >>> >>> >> a >> >> >> >>> >>> >> simple >> >> >> >>> >>> >> file, and just add database server details for the >> server to >> >> >> >>> >>> >> run >> >> >> >>> >>> >> against. >> >> >> >>> >>> >> >> >> >> >>> >>> >> - If we have configurable tests (because making them >> >> >> >>> >>> >> configurable >> >> >> >>> >>> >> adds >> >> >> >>> >>> >> genuine value), then we can use an "advanced" config >> file to >> >> >> >>> >>> >> allow >> >> >> >>> >>> >> the >> >> >> >>> >>> >> user to adjust settings as they want. >> >> >> >>> >>> >> >> >> >> >>> >>> >> In the simple case, the user should be able to run the >> tests >> >> >> >>> >>> >> successfully within a minute or two from starting. >> >> >> >>> >>> >> >> >> >> >>> >>> >> In designing the layout for files etc, remember the >> >> >> >>> >>> >> following: >> >> >> >>> >>> >> >> >> >> >>> >>> >> - Users should never edit a file that is in our source >> >> >> >>> >>> >> control. >> >> >> >>> >>> >> That's >> >> >> >>> >>> >> why we have .in files that we expect them to copy. >> >> >> >>> >>> >> >> >> >> >>> >>> >> - Unless they're an advanced user, they shouldn't need to >> >> >> >>> >>> >> copy >> >> >> >>> >>> >> the >> >> >> >>> >>> >> config file for advanced options. That means that the >> tests >> >> >> >>> >>> >> should >> >> >> >>> >>> >> have defaults that match what is in the template advanced >> >> >> >>> >>> >> config >> >> >> >>> >>> >> file >> >> >> >>> >>> >> (or, the tests could read advanced.json.in if >> advanced.json >> >> >> >>> >>> >> doesn't >> >> >> >>> >>> >> exist, though that does seem a little icky). Of course, >> >> >> >>> >>> >> those >> >> >> >>> >>> >> are >> >> >> >>> >>> >> example filenames, not necessarily what you may choose. >> >> >> >>> >>> >> >> >> >> >>> >>> >> -- >> >> >> >>> >>> >> Dave Page >> >> >> >>> >>> >> Blog: http://pgsnake.blogspot.com >> >> >> >>> >>> >> Twitter: @pgsnake >> >> >> >>> >>> >> >> >> >> >>> >>> >> EnterpriseDB UK: http://www.enterprisedb.com >> >> >> >>> >>> >> The Enterprise PostgreSQL Company >> >> >> >>> >>> > >> >> >> >>> >>> > >> >> >> >>> >>> > >> >> >> >>> >>> > >> >> >> >>> >>> > -- >> >> >> >>> >>> > Best, >> >> >> >>> >>> > Priyanka >> >> >> >>> >>> > >> >> >> >>> >>> > EnterpriseDB Corporation >> >> >> >>> >>> > The Enterprise PostgreSQL Company >> >> >> >>> >>> >> >> >> >>> >>> >> >> >> >>> >>> >> >> >> >>> >>> -- >> >> >> >>> >>> Dave Page >> >> >> >>> >>> Blog: http://pgsnake.blogspot.com >> >> >> >>> >>> Twitter: @pgsnake >> >> >> >>> >>> >> >> >> >>> >>> EnterpriseDB UK: http://www.enterprisedb.com >> >> >> >>> >>> The Enterprise PostgreSQL Company >> >> >> >>> >>> >> >> >> >>> >>> >> >> >> >>> >>> -- >> >> >> >>> >>> Sent via pgadmin-hackers mailing list >> >> >> >>> >>> (pgadmin-hackers@postgresql.org) >> >> >> >>> >>> To make changes to your subscription: >> >> >> >>> >>> http://www.postgresql.org/mailpref/pgadmin-hackers >> >> >> >>> >> >> >> >> >>> >> >> >> >> >>> >> >> >> >> >>> >> >> >> >> >>> >> -- >> >> >> >>> >> Best, >> >> >> >>> >> Priyanka >> >> >> >>> >> >> >> >> >>> >> EnterpriseDB Corporation >> >> >> >>> >> The Enterprise PostgreSQL Company >> >> >> >>> > >> >> >> >>> > >> >> >> >>> > >> >> >> >>> > >> >> >> >>> > -- >> >> >> >>> > Best, >> >> >> >>> > Priyanka >> >> >> >>> > >> >> >> >>> > EnterpriseDB Corporation >> >> >> >>> > The Enterprise PostgreSQL Company >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> -- >> >> >> >>> Dave Page >> >> >> >>> Blog: http://pgsnake.blogspot.com >> >> >> >>> Twitter: @pgsnake >> >> >> >>> >> >> >> >>> EnterpriseDB UK: http://www.enterprisedb.com >> >> >> >>> The Enterprise PostgreSQL Company >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> -- >> >> >> >> Best, >> >> >> >> Priyanka >> >> >> >> >> >> >> >> EnterpriseDB Corporation >> >> >> >> The Enterprise PostgreSQL Company >> >> >> > >> >> >> > >> >> >> > >> >> >> > >> >> >> > -- >> >> >> > Best, >> >> >> > Priyanka >> >> >> > >> >> >> > EnterpriseDB Corporation >> >> >> > The Enterprise PostgreSQL Company >> >> >> >> >> >> >> >> >> >> >> >> -- >> >> >> Dave Page >> >> >> Blog: http://pgsnake.blogspot.com >> >> >> Twitter: @pgsnake >> >> >> >> >> >> EnterpriseDB UK: http://www.enterprisedb.com >> >> >> The Enterprise PostgreSQL Company >> >> > >> >> > >> >> > >> >> > >> >> > -- >> >> > Best, >> >> > Priyanka >> >> > >> >> > EnterpriseDB Corporation >> >> > The Enterprise PostgreSQL Company >> >> >> >> >> >> >> >> -- >> >> Dave Page >> >> Blog: http://pgsnake.blogspot.com >> >> Twitter: @pgsnake >> >> >> >> EnterpriseDB UK: http://www.enterprisedb.com >> >> The Enterprise PostgreSQL Company >> > >> > >> > >> > >> > -- >> > Best, >> > Priyanka >> > >> > EnterpriseDB Corporation >> > The Enterprise PostgreSQL Company >> >> >> >> -- >> Dave Page >> Blog: http://pgsnake.blogspot.com >> Twitter: @pgsnake >> >> EnterpriseDB UK: http://www.enterprisedb.com >> The Enterprise PostgreSQL Company >> > > > > -- > Best, > Priyanka > > EnterpriseDB Corporation > The Enterprise PostgreSQL Company > --001a114b18ba9e180e05376880d4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Jul 11, 2016 at 7:15 PM, Priyanka Shendge <= ;pri= yanka.shendge@enterprisedb.com> wrote:


On 11 July 2016 at 18:35, Dave Page <dp= age@pgadmin.org> wrote:
On Mon, Jul 11, 2016 at 1:25 PM, Priyanka Shendge
<= priyanka.shendge@enterprisedb.com> wrote:
> Sorry, by mistake i copied incomplete query.=C2=A0 There is an OID pre= sent for
> added database.
>
> SELECT
>=C2=A0 =C2=A0 =C2=A0db.oid as did, db.datname, db.datallowconn,
>=C2=A0 =C2=A0 =C2=A0pg_encoding_to_char(db.encoding) AS serverencoding,=
>=C2=A0 =C2=A0 =C2=A0has_database_privilege(db.oid, 'CREATE') as= cancreate, datlastsysoid
> FROM
>=C2=A0 =C2=A0 =C2=A0pg_database db
> WHERE db.oid =3D 158579

There's nothing wrong with that query. Can you work with Khushbo= o to
see if she can reproduce or help figure it out please?

I had work with Khushboo, she also tried to reproduc= e the issue at her it's working fine for her.
Khushboo also t= ried to troubleshoot/trace the issue but not able to figure out where exact= ly its failing;
as issue was not reproducible.

@Khushboo:
=C2=A0Please add if i am missing anything.



We have tried to reproduce this issue at our end several times wit= h the different scenarios but every attempt was unsuccessful.

=
Here the newly created database connection is failing which should not= as the database is created properly as per the log.
The abov= e query (mentioned by Priyanka) executes from the psycopg2 driver and could= fail in 2 scenarios, either the database has been dropped before this part= icular test-case runs or the database is not created properly through the &= #39;create database test-case'.=C2=A0 But as per the log, the 'dele= te database test-case' runs after this test-case and the database is cr= eated properly.

Can any privilege issue prevent the database connect= ion in this scenario?

Thanks,
Khushboo
<= /div>


=C2=A0
Thanks.

> On 11 July 2016 at 17:18, Dave Page <dpage@pgadmin.org> wrote:
>>
>> Hi,
>>
>> No, sorry I don't have an extra system you can test on.
>>
>> It's pretty clear that query would fail - it's missing a d= atabase OID
>> after the =3D
>>
>> On Fri, Jul 8, 2016 at 10:38 AM, Priyanka Shendge
>> <priyanka.shendge@enterprisedb.com> wrote:
>> > Hi Dave,
>> >
>> > I have tried to reproduce the issue by running the test-suite= on
>> > different
>> > machines (64 and 32 bit) and
>> > users on PG9.4/9.5 (Provided different "test_db_username= " in
>> > test_config.json). It is working fine at my end.
>> >
>> > The log file (output.log) sent by you shows following query i= s failing
>> > at
>> > your end:
>> >
>> > SELECT
>> >=C2=A0 =C2=A0 =C2=A0db.oid as did, db.datname, db.datallowconn= ,
>> >=C2=A0 =C2=A0 =C2=A0pg_encoding_to_char(db.encoding) AS server= encoding,
>> >=C2=A0 =C2=A0 =C2=A0has_database_privilege(db.oid, 'CREATE= ') as cancreate, datlastsysoid
>> > FROM
>> >=C2=A0 =C2=A0 =C2=A0pg_database db
>> > WHERE db.oid =3D
>> >
>> > Let me know if you have an extra system where I can reproduce= the issue.
>> >
>> >
>> > On 5 July 2016 at 15:40, Dave Page <dpage@pgadmin.org> wrote:
>> >>
>> >> Attached.
>> >>
>> >> On Tue, Jul 5, 2016 at 9:00 AM, Priyanka Shendge
>> >> <priyanka.shendge@enterprisedb.com> wrote:
>> >> > Hi Dave,
>> >> >
>> >> > I tried running the testsuite against PG9.4 and unab= le to reproduce
>> >> > the
>> >> > failures.
>> >> > I have added debug statements to previous patch. Pat= ch attached.
>> >> > Could you please re-run the same and send me the log= s and output?
>> >> >
>> >> > Thank you.
>> >> >
>> >> > On 4 July 2016 at 17:30, Dave Page <dpage@pgadmin.org> wrote:<= br> >> >> >>
>> >> >> Hi
>> >> >>
>> >> >> The test data was the default, and I ran against= PG 9.4. All other
>> >> >> logs
>> >> >> were attached to my previous email.
>> >> >>
>> >> >> --
>> >> >> Dave Page
>> >> >> Blog: http://pgsnake.blogspot.com
>> >> >> Twitter: @pgsnake
>> >> >>
>> >> >> EnterpriseDB UK:http://www.enterprisedb.com
>> >> >> The Enterprise PostgreSQL Company
>> >> >>
>> >> >> On 4 Jul 2016, at 12:16, Priyanka Shendge
>> >> >> <priyanka.shendge@enterprisedb.com> wrote:=
>> >> >>
>> >> >> Hi Dave,
>> >> >>
>> >> >> I am unable to reproduce issue on my side; tried= on Python 2.7 and
>> >> >> Python
>> >> >> 3.4.
>> >> >> Could you please provide me DEBUG logs and test = data using for
>> >> >> database
>> >> >> node?
>> >> >>
>> >> >> Thank you.
>> >> >>
>> >> >> On 30 June 2016 at 00:51, Dave Page <dpage@pgadmin.org> w= rote:
>> >> >>>
>> >> >>> Hi,
>> >> >>>
>> >> >>> That's better. I tweaked a few things an= d fixed a bug related to
>> >> >>> recent changes to the schema version config.= Patch attached.
>> >> >>>
>> >> >>> However, there are still issues:
>> >> >>>
>> >> >>> 1) The testsuite doesn't run to completi= on. See the attached
>> >> >>> stdout.txt and logger.txt files.
>> >> >>> 2) stdout should only display the test summa= ry - what tests are
>> >> >>> currently running (and pass/fail), and a sum= mary at the end - even
>> >> >>> if
>> >> >>> there's a crash like I saw.
>> >> >>> 3) The output log file should contain the fu= ll output, including
>> >> >>> what's sent to stdout.
>> >> >>> 4) The output advises the user to check
>> >> >>> ".../pgadmin4/web/regression".
>> >> >>> This should be in the summary at the end, an= d should be corrected
>> >> >>> to
>> >> >>> show the correct (full) path.
>> >> >>>
>> >> >>> Thanks.
>> >> >>>
>> >> >>>
>> >> >>> On Wed, Jun 29, 2016 at 2:52 PM, Priyanka Sh= endge
>> >> >>> <priyanka.shendge@enterprisedb.com> wr= ote:
>> >> >>> > Hi Dave,
>> >> >>> >
>> >> >>> > As per discussion over mail i have crea= ted separate config files
>> >> >>> > for
>> >> >>> > credentials and test data.
>> >> >>> >
>> >> >>> > PFA patch for same. Kindly, review and = let me know for
>> >> >>> > modifications.
>> >> >>> >
>> >> >>> > On 27 June 2016 at 15:10, Priyanka Shen= dge
>> >> >>> > <priyanka.shendge@enterprisedb.com&g= t; wrote:
>> >> >>> >>
>> >> >>> >>
>> >> >>> >>
>> >> >>> >> On 27 June 2016 at 13:24, Dave Page= <dpage@pgadmin.o= rg> wrote:
>> >> >>> >>>
>> >> >>> >>> On Sun, Jun 26, 2016 at 12:05 P= M, Priyanka Shendge
>> >> >>> >>> <priyanka.shendge@enterprisedb.c= om> wrote:
>> >> >>> >>> >
>> >> >>> >>> >
>> >> >>> >>> > On 24 June 2016 at 16:17, = Dave Page <dpage@= pgadmin.org>
>> >> >>> >>> > wrote:
>> >> >>> >>> >>
>> >> >>> >>> >> Hi
>> >> >>> >>> >>
>> >> >>> >>> >> On Thu, Jun 23, 2016 a= t 2:41 PM, Priyanka Shendge
>> >> >>> >>> >> <priyanka.shendge@enter= prisedb.com> wrote:
>> >> >>> >>> >> >
>> >> >>> >>> >> >
>> >> >>> >>> >> > On 15 June 2016 a= t 15:05, Priyanka Shendge
>> >> >>> >>> >> > <priyanka.shendge@= enterprisedb.com> wrote:
>> >> >>> >>> >> >>
>> >> >>> >>> >> >> Thanks a lot = Dave.
>> >> >>> >>> >> >>
>> >> >>> >>> >> >> On 15 June 20= 16 at 14:09, Dave Page <dpage@pgadmin.org>
>> >> >>> >>> >> >> wrote:
>> >> >>> >>> >> >>>
>> >> >>> >>> >> >>> Hi
>> >> >>> >>> >> >>>
>> >> >>> >>> >> >>> On Thu, J= un 9, 2016 at 1:37 PM, Priyanka Shendge
>> >> >>> >>> >> >>> <priyanka.= shendge@enterprisedb.com> wrote:
>> >> >>> >>> >> >>> > Hi D= ave,
>> >> >>> >>> >> >>> >
>> >> >>> >>> >> >>> > PFA = updated patch. I have made changes suggested by
>> >> >>> >>> >> >>> > you.=
>> >> >>> >>> >> >>> >
>> >> >>> >>> >> >>> > Kind= ly, review and let me know for more changes.
>> >> >>> >>> >> >>>
>> >> >>> >>> >> >>> OK, I got= a bit further this time, but not there yet.
>> >> >>> >>> >> >>>
>> >> >>> >>> >> >>> 1) The pa= tch overwrote my test_config.json file. That
>> >> >>> >>> >> >>> should >> >> >>> >>> >> >>> never
>> >> >>> >>> >> >>> happen (t= hat file shouldn't be in the source tree).
>> >> >>> >>> >> >>> test_c= onfig.json.in should be the file that's included
>> >> >>> >>> >> >>> in
>> >> >>> >>> >> >>> the
>> >> >>> >>> >> >>> patch. >> >> >>> >>> >> >>
>> >> >>> >>> >> >>
>> >> >>> >>> >> >> OK.
>> >> >>> >>> >> >>>
>> >> >>> >>> >> >>>
>> >> >>> >>> >> >>> 2) The up= dated test_config.json file is huge.
>> >> >>> >>> >> >
>> >> >>> >>> >> >
>> >> >>> >>> >> > Current configura= tion file web/regression/test_config.json
>> >> >>> >>> >> > contains
>> >> >>> >>> >> > test
>> >> >>> >>> >> > data(credentials)= for each tree node;
>> >> >>> >>> >> > which is used whi= le adding and updating the respective
>> >> >>> >>> >> > node.
>> >> >>> >>> >>
>> >> >>> >>> >> Why would we need that= ?
>> >> >>> >>> >
>> >> >>> >>> >
>> >> >>> >>> > Each node file (e.g. test_= db_add.py and test_db_put.py) uses
>> >> >>> >>> > respective
>> >> >>> >>> > credentials test data=C2= =A0 from
>> >> >>> >>> > test_config.json while exe= cution.
>> >> >>> >>>
>> >> >>> >>> That doesn't answer my ques= tion - why do we need separate
>> >> >>> >>> credentials
>> >> >>> >>> for each node?
>> >> >>> >>
>> >> >>> >>
>> >> >>> >> Sorry for typo, its test data not c= redentials.
>> >> >>> >>
>> >> >>> >>>
>> >> >>> >>>
>> >> >>> >>> >> We should have just on= e set of credentials for
>> >> >>> >>> >> everything.
>> >> >>> >>> >
>> >> >>> >>> >
>> >> >>> >>> > Let me know if my understa= nding is clear:
>> >> >>> >>> >
>> >> >>> >>> > Should i keep basic creden= tials of each node (database,
>> >> >>> >>> > schema)
>> >> >>> >>> > into
>> >> >>> >>> > test_config.json
>> >> >>> >>> > instead=C2=A0 taking care = of each field?
>> >> >>> >>>
>> >> >>> >>> You should have one set of cred= entials that's used for the
>> >> >>> >>> entire
>> >> >>> >>> test
>> >> >>> >>> run.
>> >> >>> >>
>> >> >>> >>
>> >> >>> >> Sure.=C2=A0 I'll separate the c= redentials and test data into 2
>> >> >>> >> different
>> >> >>> >> files.
>> >> >>> >> So, a normal user can run the tests= into one go after some minor
>> >> >>> >> credentials changes.
>> >> >>> >> And an advanced user can have an op= tion to change the test data
>> >> >>> >> if
>> >> >>> >> he
>> >> >>> >> wants.
>> >> >>> >>>
>> >> >>> >>>
>> >> >>> >>> >> >>> I should = only need to
>> >> >>> >>> >> >>> define on= e or more connections, then be able to run the
>> >> >>> >>> >> >>> tests. >> >> >>> >>> >> >>> If
>> >> >>> >>> >> >>> you
>> >> >>> >>> >> >>> need to k= eep configuration info for "advanced users",
>> >> >>> >>> >> >>> let's=
>> >> >>> >>> >> >>> put it >> >> >>> >>> >> >>> in
>> >> >>> >>> >> >>> a differe= nt file to avoid confusing/scaring everyone
>> >> >>> >>> >> >>> else.
>> >> >>> >>> >> >>> Maybe
>> >> >>> >>> >> >>> split
>> >> >>> >>> >> >>> it into c= onfig.json for the stuff the user needs to edit
>> >> >>> >>> >> >>> (config.json= .in would go in git), and test_config.json
>> >> >>> >>> >> >>> for
>> >> >>> >>> >> >>> the
>> >> >>> >>> >> >>> test
>> >> >>> >>> >> >>> configura= tion.
>> >> >>> >>> >> >
>> >> >>> >>> >> >
>> >> >>> >>> >> > Should i keep log= in and server credentials into
>> >> >>> >>> >> > web/regression/te= st_config.json file and
>> >> >>> >>> >> > put respective no= de details into config.json file of
>> >> >>> >>> >> > respective
>> >> >>> >>> >> > node's
>> >> >>> >>> >> > tests
>> >> >>> >>> >> > directory?
>> >> >>> >>> >>
>> >> >>> >>> >> Not if you expect user= s to need to edit them - and if not,
>> >> >>> >>> >> why
>> >> >>> >>> >> are
>> >> >>> >>> >> the
>> >> >>> >>> >> values not just hard-c= oded?
>> >> >>> >>> >>
>> >> >>> >>> >> > e.g. for database= node:
>> >> >>> >>> >> > I'll create c= onfig.json file into .../databases/tests/
>> >> >>> >>> >> > directory
>> >> >>> >>> >> > put database add = and update credentials into config.json
>> >> >>> >>> >>
>> >> >>> >>> >> The key here is to mak= e it simple for users.
>> >> >>> >>> >>
>> >> >>> >>> >> - To run the default t= ests, they should be able to copy/edit
>> >> >>> >>> >> a
>> >> >>> >>> >> simple
>> >> >>> >>> >> file, and just add dat= abase server details for the server to
>> >> >>> >>> >> run
>> >> >>> >>> >> against.
>> >> >>> >>> >>
>> >> >>> >>> >> - If we have configura= ble tests (because making them
>> >> >>> >>> >> configurable
>> >> >>> >>> >> adds
>> >> >>> >>> >> genuine value), then w= e can use an "advanced" config file to
>> >> >>> >>> >> allow
>> >> >>> >>> >> the
>> >> >>> >>> >> user to adjust setting= s as they want.
>> >> >>> >>> >>
>> >> >>> >>> >> In the simple case, th= e user should be able to run the tests
>> >> >>> >>> >> successfully within a = minute or two from starting.
>> >> >>> >>> >>
>> >> >>> >>> >> In designing the layou= t for files etc, remember the
>> >> >>> >>> >> following:
>> >> >>> >>> >>
>> >> >>> >>> >> - Users should never e= dit a file that is in our source
>> >> >>> >>> >> control.
>> >> >>> >>> >> That's
>> >> >>> >>> >> why we have .in files = that we expect them to copy.
>> >> >>> >>> >>
>> >> >>> >>> >> - Unless they're a= n advanced user, they shouldn't need to
>> >> >>> >>> >> copy
>> >> >>> >>> >> the
>> >> >>> >>> >> config file for advanc= ed options. That means that the tests
>> >> >>> >>> >> should
>> >> >>> >>> >> have defaults that mat= ch what is in the template advanced
>> >> >>> >>> >> config
>> >> >>> >>> >> file
>> >> >>> >>> >> (or, the tests could r= ead advanced.json.in if advanced.json
>> >> >>> >>> >> doesn't
>> >> >>> >>> >> exist, though that doe= s seem a little icky). Of course,
>> >> >>> >>> >> those
>> >> >>> >>> >> are
>> >> >>> >>> >> example filenames, not= necessarily what you may choose.
>> >> >>> >>> >>
>> >> >>> >>> >> --
>> >> >>> >>> >> Dave Page
>> >> >>> >>> >> Blog: http://pgsnake= .blogspot.com
>> >> >>> >>> >> Twitter: @pgsnake
>> >> >>> >>> >>
>> >> >>> >>> >> EnterpriseDB UK: htt= p://www.enterprisedb.com
>> >> >>> >>> >> The Enterprise Postgre= SQL Company
>> >> >>> >>> >
>> >> >>> >>> >
>> >> >>> >>> >
>> >> >>> >>> >
>> >> >>> >>> > --
>> >> >>> >>> > Best,
>> >> >>> >>> > Priyanka
>> >> >>> >>> >
>> >> >>> >>> > EnterpriseDB Corporation >> >> >>> >>> > The Enterprise PostgreSQL = Company
>> >> >>> >>>
>> >> >>> >>>
>> >> >>> >>>
>> >> >>> >>> --
>> >> >>> >>> Dave Page
>> >> >>> >>> Blog: http://pgsnake.blogspot= .com
>> >> >>> >>> Twitter: @pgsnake
>> >> >>> >>>
>> >> >>> >>> EnterpriseDB UK: http://www.e= nterprisedb.com
>> >> >>> >>> The Enterprise PostgreSQL Compa= ny
>> >> >>> >>>
>> >> >>> >>>
>> >> >>> >>> --
>> >> >>> >>> Sent via pgadmin-hackers mailin= g list
>> >> >>> >>> (pgadmin-hackers@postgresql.org) >> >> >>> >>> To make changes to your subscri= ption:
>> >> >>> >>> http:/= /www.postgresql.org/mailpref/pgadmin-hackers
>> >> >>> >>
>> >> >>> >>
>> >> >>> >>
>> >> >>> >>
>> >> >>> >> --
>> >> >>> >> Best,
>> >> >>> >> Priyanka
>> >> >>> >>
>> >> >>> >> EnterpriseDB Corporation
>> >> >>> >> The Enterprise PostgreSQL Company >> >> >>> >
>> >> >>> >
>> >> >>> >
>> >> >>> >
>> >> >>> > --
>> >> >>> > Best,
>> >> >>> > Priyanka
>> >> >>> >
>> >> >>> > EnterpriseDB Corporation
>> >> >>> > The Enterprise PostgreSQL Company
>> >> >>>
>> >> >>>
>> >> >>>
>> >> >>> --
>> >> >>> Dave Page
>> >> >>> Blog: http://pgsnake.blogspot.com
>> >> >>> Twitter: @pgsnake
>> >> >>>
>> >> >>> EnterpriseDB UK: http://www.enterprisedb.c= om
>> >> >>> The Enterprise PostgreSQL Company
>> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >> >> --
>> >> >> Best,
>> >> >> Priyanka
>> >> >>
>> >> >> EnterpriseDB Corporation
>> >> >> The Enterprise PostgreSQL Company
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > --
>> >> > Best,
>> >> > Priyanka
>> >> >
>> >> > EnterpriseDB Corporation
>> >> > The Enterprise PostgreSQL Company
>> >>
>> >>
>> >>
>> >> --
>> >> Dave Page
>> >> Blog: http://pgsnake.blogspot.com
>> >> Twitter: @pgsnake
>> >>
>> >> EnterpriseDB UK: http://www.enterprisedb.com
>> >> The Enterprise PostgreSQL Company
>> >
>> >
>> >
>> >
>> > --
>> > Best,
>> > Priyanka
>> >
>> > EnterpriseDB Corporation
>> > The Enterprise PostgreSQL Company
>>
>>
>>
>> --
>> Dave Page
>> Blog: http://pgsnake.blogspot.com
>> Twitter: @pgsnake
>>
>> EnterpriseDB UK: http://www.enterprisedb.com
>> The Enterprise PostgreSQL Company
>
>
>
>
> --
> Best,
> Priyanka
>
> EnterpriseDB Corporation
> The Enterprise PostgreSQL Company



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

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



--
=
Best,
Priyanka

EnterpriseDB Corporation
The Enterprise Postg= reSQL Company

--001a114b18ba9e180e05376880d4--