Re: dropdb --force

po 18. 11. 2019 v 6:24 odesílatel Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
napsal:

> On Mon, Nov 18, 2019 at 10:33 AM Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
> wrote:
> >
> > po 18. 11. 2019 v 4:43 odesílatel vignesh C <vignesh21(at)gmail(dot)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.
>

+1

> 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?
>

+ 1 from me - all has sense

>
> --
> With Regards,
> Amit Kapila.
> EnterpriseDB: http://www.enterprisedb.com
>