Re: Freeze when trying to run a pg_dump backup file as SQL query

Great, thanks for the fix, Guillaume! I tested it the latest master 
version with my original 15 MB file and it no longer freezes even on 
that. (It does take a few seconds just to open the file, but that's OK.)

Regards,

Evan

On 14/07/2012 10:46 PM, Guillaume Lelarge wrote:
> On Sat, 2012-07-14 at 01:26 +1000, Evan Martin wrote:
>> No comments at all? Can anyone else at least repro this?
>>
> Don't know for others, but I was overloaded translating in french the
> PostgreSQL 9.2 manual. Now that's it's done, I can get back on hacking
> pgAdmin.
>
>> On 6/07/2012 10:33 PM, Evan Martin wrote:
>>> I've reliably reproduced the freezing bug I mentioned before (in the
>>> suggestion to save query text). pgAdmin freezes when I try to run a
>>> backup file created by pg_dump from an SQL query window. The file
>>> contents look like this:
>>>
>>> COPY much_data (some_data) FROM stdin;
>>> BLAH/BLAH/BLAH/BLAH/BLAH/BLAH/BLAH/BLAH/BLAH/BLAH/BLAH/BLAH/BLAH
>>> BLAH/BLAH/BLAH/BLAH/BLAH/BLAH/BLAH/BLAH/BLAH/BLAH/BLAH/BLAH/BLAH
>>> BLAH/BLAH/BLAH/BLAH/BLAH/BLAH/BLAH/BLAH/BLAH/BLAH/BLAH/BLAH/BLAH
>>> BLAH/BLAH/BLAH/BLAH/BLAH/BLAH/BLAH/BLAH/BLAH/BLAH/BLAH/BLAH/BLAH
>>> BLAH/BLAH/BLAH/BLAH/BLAH/BLAH/BLAH/BLAH/BLAH/BLAH/BLAH/BLAH/BLAH
>>> \.
>>>
>>> When I run that the output window shows:
>>>
>>> ERROR:  syntax error at or near "BLAH"
>>> LINE 2: BLAH/BLAH/BLAH/BLAH/BLAH/BLAH/BLAH/BLAH/BLAH/BLAH/BLAH/BLAH/...
>>>
>>> That's fine (well, it would be nice if pgAdmin supported restoring
>>> such files, but that's another story) - but then it freezes. It
>>> doesn't happen with 5 lines as above, but if I have 100 lines of data
>>> that's enough to make it freeze for a few seconds. With a real back-up
>>> file of 1 MB or more it probably won't come back any time soon and has
>>> to be killed. (It doesn't need to be real data - just copy/paste the 5
>>> BLAH lines above 20 times to reproduce the problem.)
>>>
>>> I'm running pgAdmin 1.14.3 running on Windows 7 (x64), PostgreSQL 9.1.3
>>>
> I reproduce this with something around 400 lines. We used an very
> inefficient way to find the part of the query that was wrong, to
> highlight it. This is now fixed in 1.16, and master branches.
>
>