Re: pgsql: Add tests for '-f' option in dropdb utility.

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Amit Kapila <akapila(at)postgresql(dot)org>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, pgsql-committers(at)lists(dot)postgresql(dot)org
Subject: Re: pgsql: Add tests for '-f' option in dropdb utility.
Date: 2019-11-29 16:40:50
Message-ID: CAA4eK1KUOFKGXwRQsmpqhMHppAeU+Ni0KWiMGHWZHQhBn-aJFA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers

On Fri, Nov 29, 2019 at 3:24 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>
> On Fri, Nov 29, 2019 at 7:42 AM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> >
> > On Fri, Nov 29, 2019 at 2:25 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> > >
> > > If there's no other workaround, I'm tempted to propose
> > >
> > > #ifdef WIN32
> > > pg_sleep(1 second);
> > > #endif
> > >
> > > or something close to that, before we close the socket.
> > >
> >
> > I can experiment with this or if something else occurred to me.
> >
>
> The above experiment suggested by you works and the test passes after
> this in the local Windows setup. One more thing, I think we don't
> need to do above for graceful exits and during socket_close we have
> access to exit_status_code which can be used in this context. I have
> attached the patch for this. I think something on these lines is even
> suggested by MSDN [1], but I am not sure.
>
..
>
> > > Or we could revert the whole feature.
> > >
> >
> > Yeah, that is also one possibility, but I think given we already have
> > this behavior in existing features, it is better to either come up
> > with some solution or maybe mention in docs that in such cases users
> > need to check postmaster log to know the actual reason.
> >
> > I think we can further explore this, but for now, we might want to (a)
> > revert this test, or (b) change the expected output to match.
> >
>
> I think if we decide to go with the above solution for Windows, then
> we can keep the current test as it is or probably remove one test
> related to <pid> test, otherwise, it is better to go with (a) for now
> and once we decide any solution for this we can again commit these
> tests.
>

I am planning to revert the commits (8a7e9e9dad and 290acac92b) done
for tests tomorrow morning and then separately explore the solution
for the Windows-specific problem (it drops not-yet-delivered data when
the server closes the connection) as it seems to impact multiple
features. It is quite possible that the best we can do is on the
lines of what you have suggested (sleep for short duration before
closing the socket), but there is no harm in spending some more time
and see if we can come up with something better.

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

In response to

Browse pgsql-committers by date

  From Date Subject
Next Message Amit Kapila 2019-11-30 02:33:48 pgsql: Revert commits 290acac92b and 8a7e9e9dad.
Previous Message Tom Lane 2019-11-29 16:09:06 Re: pgsql: Add a regression test for allow_system_table_mods