Обсуждение: BUG: pgScript NOT thread safe!!

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 ) BEGINPRINT  '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

Sorry, I have - of course - forgot to support the important pgAdmin and OS vewrsion information. It is pgAdmin 1.10rc1
runon Windows XP (SP3). 

Andras Fabian

- - - - - - - - - - - - - -

IT
mailto:fabian@atrada.net

Atrada Trading Network AG


-----Ursprüngliche Nachricht-----
Von: Andras Fabian
Gesendet: Donnerstag, 25. Juni 2009 16:51
An: 'pgadmin-support@postgresql.org'
Betreff: BUG: pgScript NOT thread safe!!

Hi pgAdmin developers,

We are users of your great tool pgAdmin since we started migrating projects to PostgreSQl. But just two days ago we
noticeda 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
pgScriptcode 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
windowsat the same time (he needed to run it against many diferent DBs). As he had some PRINT outputs to monitor the
advanceof 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
runthem it TWO query windows (but started from the same pgAdmin process!) I could notice the weirdest behaviors one
couldexpect. The most usual was early termination of the loop - without error messages - but there were also loops
whichthen run much longer as their target value would have suggested. In one case, we even got an "unhandled exception"
whichcompletely 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
pgAdmintwice and opened one Query window in each), everything was fine. We could run the script as often as we wanted
(andthe 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
omittedin 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
specificrange. 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
doa maintenance task (the same task) for many DBs or Servers, you might easily come up with the idea to do it from many
querywindows. 

Finally, I would - of course - share the simple script, which helps to reproduce the odd behavior. With it, I hope, you
canquickly pinpoint the issue and fix it. Before that I would recommend to issue a warning to users, to never run more
thenone 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
Imean: 
-------------------------------------------------------
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 ) BEGINPRINT  '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

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
>



--
Dave Page
EnterpriseDB UK:   http://www.enterprisedb.com

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

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

Ashesh Vashi 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.

I'd rather see something that throws up a messagebox informing the user
that parallel execution of pgscript is not supported, if this is the
route we have to go down.

-- Magnus HaganderSelf: http://www.hagander.net/Work: http://www.redpill-linpro.com/

2009/6/25 Magnus Hagander <magnus@hagander.net>:
> Ashesh Vashi 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.
>
> I'd rather see something that throws up a messagebox informing the user
> that parallel execution of pgscript is not supported, if this is the
> route we have to go down.
>
> --
>  Magnus Hagander
>  Self: http://www.hagander.net/
>  Work: http://www.redpill-linpro.com/
>

Hi,

Very sorry for this bug. I did not take into account the case when one
uses 2 or more Query tool windows. If one launches two windows, it
will create two pgsApplication. However, it will use the same
Flex/Bison parser. Actually I can''t do anything about Flex & Bison
not supporting multiple threads.

So the only immediate fix I see is the one provided by Ashesh plus
showing a message box when a script is running saying that a script is
already running (Magnus suggestion). I do not currently have a
development environment up-to-date: Ashesh, could you add the message
box please?

I write down this bug in my TODO list and will try to manage it better
later. Once again, sorry for this bug.

Regards,
Mickael

That was my thought Ashesh - plus we could push out 1.10.1 pretty soon
with a long-term solution.

On 6/25/09, Ashesh Vashi <ashesh.vashi@enterprisedb.com> wrote:
> Hi Mickael/Dave,
>
> Mickael Deloison wrote:
>> 2009/6/25 Magnus Hagander <magnus@hagander.net>:
>>> Ashesh Vashi 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.
>>> I'd rather see something that throws up a messagebox informing the user
>>> that parallel execution of pgscript is not supported, if this is the
>>> route we have to go down.
>>>
>>> --
>>>  Magnus Hagander
>>>  Self: http://www.hagander.net/
>>>  Work: http://www.redpill-linpro.com/
>>>
>>
>> Hi,
>>
>> Very sorry for this bug. I did not take into account the case when one
>> uses 2 or more Query tool windows. If one launches two windows, it
>> will create two pgsApplication. However, it will use the same
>> Flex/Bison parser. Actually I can''t do anything about Flex & Bison
>> not supporting multiple threads.
>>
>> So the only immediate fix I see is the one provided by Ashesh plus
>> showing a message box when a script is running saying that a script is
>> already running (Magnus suggestion). I do not currently have a
>> development environment up-to-date: Ashesh, could you add the message
>> box please?
> I agree.
> But, as the release is in one/two days, I did not want to introduce any
> new message. :(
> (It will be added work for the translations at 11'o clock.)
> If you still insist, I can send the updated patch.
>
> --
> Thanks & Regards,
> Ashesh Vashi
>
> EnterpriseDB INDIA: http://www.enterprisedb.com
>


-- 
Dave Page
EnterpriseDB UK:   http://www.enterprisedb.com

Mickael Deloison wrote:
> 2009/6/25 Magnus Hagander <magnus@hagander.net>:
>> Ashesh Vashi 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.
>> I'd rather see something that throws up a messagebox informing the user
>> that parallel execution of pgscript is not supported, if this is the
>> route we have to go down.
>>
>> --
>>  Magnus Hagander
>>  Self: http://www.hagander.net/
>>  Work: http://www.redpill-linpro.com/
>>
> 
> Hi,
> 
> Very sorry for this bug. I did not take into account the case when one
> uses 2 or more Query tool windows. If one launches two windows, it
> will create two pgsApplication. However, it will use the same
> Flex/Bison parser. Actually I can''t do anything about Flex & Bison
> not supporting multiple threads.

Admitting to not remembering the code around this:

Can we put the mutex around just the flex/bison part? Meaning is the
output they generate ok, just not the intermediate state?

I bet the flex/bison step is very short -whereas the execution of the
full script can take a long time..



-- Magnus HaganderSelf: http://www.hagander.net/Work: http://www.redpill-linpro.com/

Dave Page wrote:
> That was my thought Ashesh - plus we could push out 1.10.1 pretty soon
> with a long-term solution.

I still think it's better with a message. Even if it's not translated
for everybody. (And yes, I realize the issue for translators)

But I'll defer to you if you think it's better to just block. I'm
worried about the length of the block leading to UI freezes though...

-- Magnus HaganderSelf: http://www.hagander.net/Work: http://www.redpill-linpro.com/

<tt>Hi Mickael/Dave,<br /><br /> Mickael Deloison wrote:</tt><blockquote
cite="mid:1f8f052b0906251055l20d2603bocd789e2eb281ee8d@mail.gmail.com"type="cite"><pre wrap=""><tt>2009/6/25 Magnus
Hagander<a class="moz-txt-link-rfc2396E" href="mailto:magnus@hagander.net"><magnus@hagander.net></a>:
 
</tt></pre><blockquote type="cite"><pre wrap=""><tt>Ashesh Vashi wrote:
</tt></pre><blockquote type="cite"><pre wrap=""><tt> 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.
</tt></pre></blockquote><pre wrap=""><tt>I'd rather see something that throws up a messagebox informing the user
that parallel execution of pgscript is not supported, if this is the
route we have to go down.

--
 Magnus Hagander
 Self: <a class="moz-txt-link-freetext" href="http://www.hagander.net/">http://www.hagander.net/</a>
 Work: <a class="moz-txt-link-freetext" href="http://www.redpill-linpro.com/">http://www.redpill-linpro.com/</a>

</tt></pre></blockquote><pre wrap=""><tt>
Hi,

Very sorry for this bug. I did not take into account the case when one
uses 2 or more Query tool windows. If one launches two windows, it
will create two pgsApplication. However, it will use the same
Flex/Bison parser. Actually I can''t do anything about Flex & Bison
not supporting multiple threads.

So the only immediate fix I see is the one provided by Ashesh plus
showing a message box when a script is running saying that a script is
already running (Magnus suggestion). I do not currently have a
development environment up-to-date: Ashesh, could you add the message
box please?
</tt></pre></blockquote><tt>I agree.<br /> But, as the release is in one/two days, I did not want to introduce any new
message.:(<br /> (It will be added work for the translations at 11'o clock.)<br /> If you still insist, I can send the
updatedpatch.<br /></tt><tt><br /></tt><div class="moz-signature"><tt>-- <br /></tt><div class="moz-signature"><tt>
<fontcolor="#666666">Thanks & Regards,<br /> Ashesh Vashi<br /><br /> EnterpriseDB INDIA: <a
href="http://www.enterprisedb.com">http://www.enterprisedb.com</a></font> </tt></div></div> 

Dave Page wrote:

That was my thought Ashesh - plus we could push out 1.10.1 pretty soon
with a long-term solution.

I still think it's better with a message. Even if it's not translated
for everybody. (And yes, I realize the issue for translators)

But I'll defer to you if you think it's better to just block. I'm
worried about the length of the block leading to UI freezes though... 

Le jeudi 25 juin 2009 à 20:37:40, Ashesh Vashi a écrit :
> Hi Dave,
>
> Please find the updated patch.
> I have realized that parallel execution of the queries is possible,
> which I had disabled in the previous patch. :(
>
> Please find the updated patches (v2.1 - with message-box & v2.2 -
> without message box).
> (Though I prefer the patch with the message box, I don't like the to add
> last moment translation messages. :( )

Actually I don't like it too. But if it's only one message, that's not a big
issue. There are only 3 languages at 100% :-(


--
Guillaume.http://www.postgresqlfr.orghttp://dalibo.com

On Thu, Jun 25, 2009 at 7:37 PM, Ashesh
Vashi<ashesh.vashi@enterprisedb.com> wrote:
> Hi Dave,
>
> Please find the updated patch.
> I have realized that parallel execution of the queries is possible, which I
> had disabled in the previous patch. :(

OK, thats weird. It doesn't work for me on Windows or Mac, but it sure
looks like it should. I've attached my version of the patch with
updated error message, qualified names for the mutex and removed
white-space changes. Can you see what's up?


--
Dave Page
EnterpriseDB UK:   http://www.enterprisedb.com

On Fri, Jun 26, 2009 at 5:50 AM, Ashesh
Vashi<ashesh.vashi@enterprisedb.com> wrote:

> That's really weird.
> I tried that patch on windows and found that - the behavior of wxMutex is
> not as expected. :(
>
> On Gtk (Ubuntu 9.04 32bit), the message-box does not adjust to the length of
> the title message.
> (Please find the attached screen-shot.)
>
> Please find the updated patch, it is working on gtk & windows both.
> Though it has not been tested on Osx, but I think - it should work.

Per IM discussion, I've removed the mutex altogether. This code all
gets called in the primary UI thread, so there's actually no
concurrency issue until the script actually starts, thus we can
protect it with a simple static bool.

I suspect this is why the mutex didn't behave as expected - it's
intended to keep different threads out of the protected area.

Tests OK on OSX.

--
Dave Page
EnterpriseDB UK:   http://www.enterprisedb.com

On Thu, Jun 25, 2009 at 6:55 PM, Mickael Deloison<mdeloison@gmail.com> wrote:

> Very sorry for this bug. I did not take into account the case when one
> uses 2 or more Query tool windows. If one launches two windows, it
> will create two pgsApplication. However, it will use the same
> Flex/Bison parser. Actually I can''t do anything about Flex & Bison
> not supporting multiple threads.

No problem - these things happen.

> So the only immediate fix I see is the one provided by Ashesh plus
> showing a message box when a script is running saying that a script is
> already running (Magnus suggestion). I do not currently have a
> development environment up-to-date: Ashesh, could you add the message
> box please?

We're blundering through working up a suitable interlock.

> I write down this bug in my TODO list and will try to manage it better
> later. Once again, sorry for this bug.

Added to our new tracker: http://code.pgadmin.org/trac/ticket/12


-- 
Dave Page
EnterpriseDB UK:   http://www.enterprisedb.com

<tt>Looks good.<br /> Working fine on linux and windows :)<br /><br /> Dave Page wrote:</tt><blockquote
cite="mid:937d27e10906260111w43c18824u86a36bf2ed116948@mail.gmail.com"type="cite"><pre wrap=""><tt>On Fri, Jun 26, 2009
at5:50 AM, Ashesh
 
Vashi<a class="moz-txt-link-rfc2396E"
href="mailto:ashesh.vashi@enterprisedb.com"><ashesh.vashi@enterprisedb.com></a>wrote:
 

</tt></pre><blockquote type="cite"><pre wrap=""><tt>That's really weird.
I tried that patch on windows and found that - the behavior of wxMutex is
not as expected. :(

On Gtk (Ubuntu 9.04 32bit), the message-box does not adjust to the length of
the title message.
(Please find the attached screen-shot.)

Please find the updated patch, it is working on gtk & windows both.
Though it has not been tested on Osx, but I think - it should work.
</tt></pre></blockquote><pre wrap=""><tt>
Per IM discussion, I've removed the mutex altogether. This code all
gets called in the primary UI thread, so there's actually no
concurrency issue until the script actually starts, thus we can
protect it with a simple static bool.

I suspect this is why the mutex didn't behave as expected - it's
intended to keep different threads out of the protected area.

Tests OK on OSX.</tt> </pre></blockquote><tt></tt><div class="moz-signature"><tt>-- <br /></tt><div
class="moz-signature"><tt><font color="#666666">Thanks & Regards,<br /> Ashesh Vashi<br /><br /> EnterpriseDB
INDIA:<a href="http://www.enterprisedb.com">http://www.enterprisedb.com</a></font></tt></div></div> 

On Fri, Jun 26, 2009 at 9:57 AM, Ashesh
Vashi<ashesh.vashi@enterprisedb.com> wrote:
> Looks good.
> Working fine on linux and windows :)

Thanks - I'll commit it.

-- 
Dave Page
EnterpriseDB UK:   http://www.enterprisedb.com