Thread: Maintenance form exection thread
Hi! Am I reading things right that we actually execute things from the maintenance dialog (like VACUUM) on a separate thread, to keep the UI responsive? Yet, it keeps hanging when we do that. My guess is that we're "using up" the connection we have, and as soon as somebody else needs access to the connection to do things like refresh tree information, we hang and wait. Or am I reading this wrong? If we are, should we perhaps consider firing off these jobs on a separate connection? -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
On Tue, Apr 6, 2010 at 6:11 PM, Magnus Hagander <magnus@hagander.net> wrote: > Hi! > > Am I reading things right that we actually execute things from the > maintenance dialog (like VACUUM) on a separate thread, to keep the UI > responsive? Yet, it keeps hanging when we do that. My guess is that > we're "using up" the connection we have, and as soon as somebody else > needs access to the connection to do things like refresh tree > information, we hang and wait. Or am I reading this wrong? > > If we are, should we perhaps consider firing off these jobs on a > separate connection? Yeah, that would seem like a sensible idea. At first thought I guessed it was an issue like this http://svn.pgadmin.org/cgi-bin/viewcvs.cgi?rev=6458&view=rev, but on reflection I think your much more simple explanation is the likely cause. -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com
On Tue, Apr 6, 2010 at 21:01, Dave Page <dpage@pgadmin.org> wrote: > On Tue, Apr 6, 2010 at 6:11 PM, Magnus Hagander <magnus@hagander.net> wrote: >> Hi! >> >> Am I reading things right that we actually execute things from the >> maintenance dialog (like VACUUM) on a separate thread, to keep the UI >> responsive? Yet, it keeps hanging when we do that. My guess is that >> we're "using up" the connection we have, and as soon as somebody else >> needs access to the connection to do things like refresh tree >> information, we hang and wait. Or am I reading this wrong? >> >> If we are, should we perhaps consider firing off these jobs on a >> separate connection? > > Yeah, that would seem like a sensible idea. At first thought I guessed > it was an issue like this > http://svn.pgadmin.org/cgi-bin/viewcvs.cgi?rev=6458&view=rev, but on > reflection I think your much more simple explanation is the likely > cause. I don' t have time to look into it right onw. Do you, or should I just add a ticket for it for "eventual fixing"? -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
Le 06/04/2010 21:48, Magnus Hagander a écrit : > On Tue, Apr 6, 2010 at 21:01, Dave Page <dpage@pgadmin.org> wrote: >> On Tue, Apr 6, 2010 at 6:11 PM, Magnus Hagander <magnus@hagander.net> wrote: >>> Hi! >>> >>> Am I reading things right that we actually execute things from the >>> maintenance dialog (like VACUUM) on a separate thread, to keep the UI >>> responsive? Yet, it keeps hanging when we do that. My guess is that >>> we're "using up" the connection we have, and as soon as somebody else >>> needs access to the connection to do things like refresh tree >>> information, we hang and wait. Or am I reading this wrong? >>> >>> If we are, should we perhaps consider firing off these jobs on a >>> separate connection? >> >> Yeah, that would seem like a sensible idea. At first thought I guessed >> it was an issue like this >> http://svn.pgadmin.org/cgi-bin/viewcvs.cgi?rev=6458&view=rev, but on >> reflection I think your much more simple explanation is the likely >> cause. > > I don' t have time to look into it right onw. Do you, or should I just > add a ticket for it for "eventual fixing"? > Add the ticket, I will take care of it this week if no one does. -- Guillaume. http://www.postgresqlfr.org http://dalibo.com
Le 06/04/2010 22:33, Guillaume Lelarge a écrit : > Le 06/04/2010 21:48, Magnus Hagander a écrit : >> On Tue, Apr 6, 2010 at 21:01, Dave Page <dpage@pgadmin.org> wrote: >>> On Tue, Apr 6, 2010 at 6:11 PM, Magnus Hagander <magnus@hagander.net> wrote: >>>> Hi! >>>> >>>> Am I reading things right that we actually execute things from the >>>> maintenance dialog (like VACUUM) on a separate thread, to keep the UI >>>> responsive? Yet, it keeps hanging when we do that. My guess is that >>>> we're "using up" the connection we have, and as soon as somebody else >>>> needs access to the connection to do things like refresh tree >>>> information, we hang and wait. Or am I reading this wrong? >>>> >>>> If we are, should we perhaps consider firing off these jobs on a >>>> separate connection? >>> >>> Yeah, that would seem like a sensible idea. At first thought I guessed >>> it was an issue like this >>> http://svn.pgadmin.org/cgi-bin/viewcvs.cgi?rev=6458&view=rev, but on >>> reflection I think your much more simple explanation is the likely >>> cause. >> >> I don' t have time to look into it right onw. Do you, or should I just >> add a ticket for it for "eventual fixing"? >> > > Add the ticket, I will take care of it this week if no one does. > Here is a patch for trunk. Oh, and one question. You created a *bug* ticket. Do you mean you want this applied on the 1.10 branch? I prefer to ask as I don't really think this is a bug, it's more of an enhancement to me. -- Guillaume. http://www.postgresqlfr.org http://dalibo.com
Attachment
On Sat, Apr 10, 2010 at 10:58, Guillaume Lelarge <guillaume@lelarge.info> wrote: > Le 06/04/2010 22:33, Guillaume Lelarge a écrit : >> Le 06/04/2010 21:48, Magnus Hagander a écrit : >>> On Tue, Apr 6, 2010 at 21:01, Dave Page <dpage@pgadmin.org> wrote: >>>> On Tue, Apr 6, 2010 at 6:11 PM, Magnus Hagander <magnus@hagander.net> wrote: >>>>> Hi! >>>>> >>>>> Am I reading things right that we actually execute things from the >>>>> maintenance dialog (like VACUUM) on a separate thread, to keep the UI >>>>> responsive? Yet, it keeps hanging when we do that. My guess is that >>>>> we're "using up" the connection we have, and as soon as somebody else >>>>> needs access to the connection to do things like refresh tree >>>>> information, we hang and wait. Or am I reading this wrong? >>>>> >>>>> If we are, should we perhaps consider firing off these jobs on a >>>>> separate connection? >>>> >>>> Yeah, that would seem like a sensible idea. At first thought I guessed >>>> it was an issue like this >>>> http://svn.pgadmin.org/cgi-bin/viewcvs.cgi?rev=6458&view=rev, but on >>>> reflection I think your much more simple explanation is the likely >>>> cause. >>> >>> I don' t have time to look into it right onw. Do you, or should I just >>> add a ticket for it for "eventual fixing"? >>> >> >> Add the ticket, I will take care of it this week if no one does. >> > > Here is a patch for trunk. > > Oh, and one question. You created a *bug* ticket. Do you mean you want > this applied on the 1.10 branch? I prefer to ask as I don't really think > this is a bug, it's more of an enhancement to me. I do consider it a bug. If it's backpatchable or not depends on the patch complexity, imo. Given that the solution is creating a separate connection for it, I think it should *not* be applied to 1.10, because it's a large problem. If someone had corrected my diagnosis and found a lower-impact way, then it could've been. The patch looks surprisingly simple :-) But I can't see why it wouldn't be correct - looks good to me. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
Le 10/04/2010 11:14, Magnus Hagander a écrit : > On Sat, Apr 10, 2010 at 10:58, Guillaume Lelarge <guillaume@lelarge.info> wrote: >> Le 06/04/2010 22:33, Guillaume Lelarge a écrit : >>> Le 06/04/2010 21:48, Magnus Hagander a écrit : >>>> On Tue, Apr 6, 2010 at 21:01, Dave Page <dpage@pgadmin.org> wrote: >>>>> On Tue, Apr 6, 2010 at 6:11 PM, Magnus Hagander <magnus@hagander.net> wrote: >>>>>> Hi! >>>>>> >>>>>> Am I reading things right that we actually execute things from the >>>>>> maintenance dialog (like VACUUM) on a separate thread, to keep the UI >>>>>> responsive? Yet, it keeps hanging when we do that. My guess is that >>>>>> we're "using up" the connection we have, and as soon as somebody else >>>>>> needs access to the connection to do things like refresh tree >>>>>> information, we hang and wait. Or am I reading this wrong? >>>>>> >>>>>> If we are, should we perhaps consider firing off these jobs on a >>>>>> separate connection? >>>>> >>>>> Yeah, that would seem like a sensible idea. At first thought I guessed >>>>> it was an issue like this >>>>> http://svn.pgadmin.org/cgi-bin/viewcvs.cgi?rev=6458&view=rev, but on >>>>> reflection I think your much more simple explanation is the likely >>>>> cause. >>>> >>>> I don' t have time to look into it right onw. Do you, or should I just >>>> add a ticket for it for "eventual fixing"? >>>> >>> >>> Add the ticket, I will take care of it this week if no one does. >>> >> >> Here is a patch for trunk. >> >> Oh, and one question. You created a *bug* ticket. Do you mean you want >> this applied on the 1.10 branch? I prefer to ask as I don't really think >> this is a bug, it's more of an enhancement to me. > > I do consider it a bug. > > If it's backpatchable or not depends on the patch complexity, imo. Applies good, needs to fix the CreateConn call (because we don't support the application_name in 1.10), compiles great then, and works great too. > Given that the solution is creating a separate connection for it, I > think it should *not* be applied to 1.10, because it's a large > problem. If someone had corrected my diagnosis and found a > lower-impact way, then it could've been. > > The patch looks surprisingly simple :-) But I can't see why it > wouldn't be correct - looks good to me. > OK, will apply to trunk. -- Guillaume. http://www.postgresqlfr.org http://dalibo.com