On Mon, Nov 18, 2019 at 10:33 AM Pavel Stehule <pavel.steh...@gmail.com> wrote:
>
> po 18. 11. 2019 v 4:43 odesÃlatel vignesh C <vignes...@gmail.com> napsal:
>>
>>
>> When we don't specify -e option, the query used to drop db will not be
>> printed like below:
>> ./dropdb testdb1
>> When we specify -e option, the query used to drop db will be printed like
>> below:
>> ./dropdb -e testdb2
>> SELECT pg_catalog.set_config('search_path', '', false);
>> DROP DATABASE testdb2;
>> If we specify -e option, the query that is being used to drop db will
>> be printed. In the existing test I could not see the inclusion of -e
>> option. I was thinking to add a test including -e that way the query
>> that includes force option gets validated.
>
>
> still I don't understand. The created query is tested already by current test.
>
> Do you want to test just -e option?
>Yeah, it seems Vignesh wants to do that. It will help in verifying that the command generated by code is correct. However, I think there is no pressing need to have an additional test for this. > Then it should be done as separate issue. > Yeah, I agree. I think this can be done as a separate test patch to improve coverage if someone wants. >> >> >> >> >> Also should we include one test where one session is connected to db >> >> and another session tries dropping with -f option? >> > >> > >> > I afraid so test API doesn't allow asynchronous operations. Do you have >> > any idea, how to it? >> > >> >> I had seen that isolation test(src/test/isolation) has a framework to >> support this. You can have a look to see if it can be handled using >> that. > > > I'll look there > If we want to have a test for this, then you might want to look at test src/test/recovery/t/013_crash_restart. In that test, we keep a connection open and then validate whether it is terminated. Having said that, I think it might be better to add this as a separate test patch apart from main patch because it is a bit of a timing-dependent test and might fail on some slow machines. We can always revert this if it turns out to be an unstable test. I have slightly modified the main patch and attached is the result. Basically, I don't see any need to repeat what is mentioned in the Drop Database page. Let me know what you guys think? -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
dropdb-f-20191118.amit.patch
Description: Binary data
