Re: BUG: pgScript NOT thread safe!!
От | Dave Page |
---|---|
Тема | Re: BUG: pgScript NOT thread safe!! |
Дата | |
Msg-id | 937d27e10906251035l1deef018n51ab86b58dd88795@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: BUG: pgScript NOT thread safe!! (Ashesh Vashi <ashesh.vashi@enterprisedb.com>) |
Список | pgadmin-support |
No, thats what i figured. I assume the second script will just wait on the mutex before continuing automatically when the first finishes? (can't check atm - on iphone) Thanks! On 6/25/09, Ashesh Vashi <ashesh.vashi@enterprisedb.com> wrote: > Hi Dave, > > This patch does the job. > But, it will not be able disable to toolbar buttons on each windows. > Introduced a static variable of type wxMutex for these operations. > > Please take a look at it. > > Dave Page wrote: >> Mickael; Is this something that can be fixed quickly and easily? We're >> building the releases first thing tomorrow, UK time and unfortunately >> I can't delay as we're committed to the PostgreSQL release timing. >> >> Ashesh; in case Mickael doesn't see this in time, can you please work >> up a quick hack in pgadmin to prevent multiple scripts being run at >> any one time? Probably a conveniently placed wxMutex will do the job. >> >> Thanks for the report Andras. >> >> On Thu, Jun 25, 2009 at 3:50 PM, Andras Fabian<Fabian@atrada.net> wrote: >>> Hi pgAdmin developers, >>> >>> We are users of your great tool pgAdmin since we started migrating >>> projects to PostgreSQl. But just two days ago we noticed a very nasty >>> bug in the otherwise very great little tool pgScript. >>> >>> One of our developers needed to fire a lot of updates for a specific >>> range of values, so he wrote a neat little pgScript code to do it. >>> Essentially only a loop with some variables which are incremented and >>> passed to an UPDATE statement. But some days ago he also noticed a very >>> nasty behavior while running two pgScript in two different query windows >>> at the same time (he needed to run it against many diferent DBs). As he >>> had some PRINT outputs to monitor the advance of his script he noticed, >>> that one script got some absolutely wrong values for one of his >>> variables. >>> >>> The I wrote a simplified version of the loop - even left out the SQL >>> code (!) - to look what happens. And as soon as I run them it TWO query >>> windows (but started from the same pgAdmin process!) I could notice the >>> weirdest behaviors one could expect. The most usual was early >>> termination of the loop - without error messages - but there were also >>> loops which then run much longer as their target value would have >>> suggested. In one case, we even got an "unhandled exception" which >>> completely nuked pgAdmin. >>> >>> As soon as we did not run in TWO threads in ONE process, but instead run >>> the Query in two different processes (started pgAdmin twice and opened >>> one Query window in each), everything was fine. We could run the script >>> as often as we wanted (and the same time as the other was running) and >>> nothing went wrong. The script went just trough deterministically. >>> >>> So, from this observations I would dare to say, that this looks like >>> some very basic "thread safety" precautions were omitted in the pgScript >>> code. >>> >>> I would also say, that this is a dangerous BUG! Think about a similar >>> script like ours, which has to delete data from a specific range. Now, >>> what if it deletes more, because the LOOP runs longer?` >>> >>> And you might also ask, why the hell we would run more than one similar >>> scripts at the same time? Well, if you need to do a maintenance task >>> (the same task) for many DBs or Servers, you might easily come up with >>> the idea to do it from many query windows. >>> >>> Finally, I would - of course - share the simple script, which helps to >>> reproduce the odd behavior. With it, I hope, you can quickly pinpoint >>> the issue and fix it. Before that I would recommend to issue a warning >>> to users, to never run more then one pgScript rom the same process. >>> >>> Here is the Script, start it from two query windows (from one process) >>> at the same time, and you should easily see what I mean: >>> ------------------------------------------------------- >>> DECLARE @v_package; >>> DECLARE @v_purchaseidmin; >>> DECLARE @v_purchaseidmax; >>> >>> DECLARE @v_to; >>> DECLARE @v_from; >>> DECLARE @v_i; >>> >>> SET @v_package = 10; >>> SET @v_purchaseidmin = 0; >>> SET @v_purchaseidmax = 120000000; >>> >>> SET @v_from = @v_purchaseidmin; >>> SET @v_to = (@v_purchaseidmin + @v_package); >>> SET @v_i = 1; >>> >>> >>> WHILE ( @v_from <= @v_purchaseidmax ) BEGIN >>> >>> PRINT 'from: ' + CAST(@v_from AS STRING); >>> PRINT 'to: ' + CAST(@v_to AS STRING); >>> PRINT 'i: ' + CAST(@v_i AS STRING); >>> >>> -- some SQL code could be executed here >>> >>> SET @v_from = (@v_from + @v_package); >>> SET @v_to = (@v_to + @v_package); >>> SET @v_i = @v_i+1; >>> END >>> ------------------------------------------------------- >>> >>> >>> Andras Fabian >>> >>> - - - - - - - - - - - - - - >>> >>> IT >>> mailto:fabian@atrada.net >>> >>> Atrada Trading Network AG >>> >>> -- >>> Sent via pgadmin-support mailing list (pgadmin-support@postgresql.org) >>> To make changes to your subscription: >>> http://www.postgresql.org/mailpref/pgadmin-support > -- > Thanks & Regards, > Ashesh Vashi > > EnterpriseDB INDIA: http://www.enterprisedb.com > -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com
В списке pgadmin-support по дате отправления: