Обсуждение: Grid editor crash during row insert
PGAdmin III 1.8 Beta 5 Windows 2000 Still stable crash during insert rows in table over grid editor. For crash need sequential insert 128-130 rows without closing grid editor. Best regards,Alexander Kirpa
Alexander Kirpa wrote: > PGAdmin III 1.8 Beta 5 > Windows 2000 > > Still stable crash during insert rows in table over grid editor. > For crash need sequential insert 128-130 rows without closing grid > editor. I nearly gave myself RSI just testing this once! I can't see anything obviously wrong, but it crashed suspiciously close to the default cache size, so I've upped that to 500 in SVN. Please test the next version when it's ready today or (more likely) tomorrow. Thanks, Dave.
On 8 Oct 2007, at 15:02, Dave Page wrote:
> Alexander Kirpa wrote:
> > PGAdmin III 1.8 Beta 5
> > Windows 2000
> >
> > Still stable crash during insert rows in table over grid editor. For
> > crash need sequential insert 128-130 rows without closing grid
> > editor.
>
> I nearly gave myself RSI just testing this once! I can't see anything
> obviously wrong, but it crashed suspiciously close to the default
> cache size, so I've upped that to 500 in SVN. Please test the next
> version when it's ready today or (more likely) tomorrow.
>
> Thanks, Dave.
In first: thank for many useful improvement from previous versions,
but
0. Grid editor not crash PgAdmin (Version 1.8.0 RC1) after 250
inserts - thank.
1. Need retrieve fresh copy of function/trigger function (especially
trigger function, each have 2 local copy in PgAdmin DB presentation
tree) from server before allow editing - for avoid too annoying
message that you see at end editing about old/expired/nonfresh
edition of (trigger) function plus chance edit expired function.
2. 'Parameters' tab do not need for trigger function - eat only place
3. Bottom field for 'Help', 'Apply', 'OK' and 'Cancel' button too
high - IMHO normal size of space bottom 'Help' should equal to space
at above this buttons.
4. Something wrong with 'Limit bar' and 'Database bar' - see garbage
under bar during movement left-right
5. Window with already edited function body still no question close
in case press 'ESC' :-(
6. No way determine stripped (partially displayed) or not value in
grid result table ('Output pane'->'Data Output') of 'Query' window,
for instance try see field name 'i8' type 'bigint' with value
'12345678901234567890'. Possible exist reason change 'autoadjust'
field width to old behavior (max field value width) or use shift/ctrl
sense double click for select behavior.
7. Wrong FK 'Properties...' presentation for 'ALTER TABLE
ttttttttttt_ttttttt ADD CONSTRAINT fffffffffff_fffffff_ffffff_ffff FOREIGN KEY (oooooo,
ssss) REFERENCES productword_advertiser (oooooo, ssss) MATCH SIMPLE ON UPDATE NO ACTION ON DELETE NO ACTION;' -
Strangeshift and
strip last char in 'ssss' - displayed as 'sss'
Best regards,Alexander Kirpa
Alexander Kirpa wrote:
> On 8 Oct 2007, at 15:02, Dave Page wrote:
>
>> Alexander Kirpa wrote:
>>> PGAdmin III 1.8 Beta 5
>>> Windows 2000
>>>
>>> Still stable crash during insert rows in table over grid editor. For
>>> crash need sequential insert 128-130 rows without closing grid
>>> editor.
>> I nearly gave myself RSI just testing this once! I can't see anything
>> obviously wrong, but it crashed suspiciously close to the default
>> cache size, so I've upped that to 500 in SVN. Please test the next
>> version when it's ready today or (more likely) tomorrow.
>>
>> Thanks, Dave.
>
> In first: thank for many useful improvement from previous versions,
> but
> 0. Grid editor not crash PgAdmin (Version 1.8.0 RC1) after 250
> inserts - thank.
NP. Thanks for testing.
> 1. Need retrieve fresh copy of function/trigger function (especially
> trigger function, each have 2 local copy in PgAdmin DB presentation
> tree) from server before allow editing - for avoid too annoying
> message that you see at end editing about old/expired/nonfresh
> edition of (trigger) function plus chance edit expired function.
Yeah, unfortunately there's no infrastructure to link the two objects
together at the moment. This was discussed a month or so back.
> 2. 'Parameters' tab do not need for trigger function - eat only place
Agreed. It won't be going for 1.8 though.
> 3. Bottom field for 'Help', 'Apply', 'OK' and 'Cancel' button too
> high - IMHO normal size of space bottom 'Help' should equal to space
> at above this buttons.
There is actually a status bar below the buttons which is used in some
circumstances.
> 4. Something wrong with 'Limit bar' and 'Database bar' - see garbage
> under bar during movement left-right
I see a tiny drawing artifact. That's wxWidgets though I believe.
> 5. Window with already edited function body still no question close
> in case press 'ESC' :-(
We don't ever query the user if a dialogue is cancelled.
> 6. No way determine stripped (partially displayed) or not value in
> grid result table ('Output pane'->'Data Output') of 'Query' window,
> for instance try see field name 'i8' type 'bigint' with value
> '12345678901234567890'. Possible exist reason change 'autoadjust'
> field width to old behavior (max field value width) or use shift/ctrl
> sense double click for select behavior.
I don't understand the problem. 12345678901234567890 is out of range for
a bigint so should never be returned as one. Please provide a self
contained test case to illustrate the problem.
> 7. Wrong FK 'Properties...' presentation for 'ALTER TABLE
> ttttttttttt_ttttttt
> ADD CONSTRAINT fffffffffff_fffffff_ffffff_ffff FOREIGN KEY (oooooo,
> ssss)
> REFERENCES productword_advertiser (oooooo, ssss) MATCH SIMPLE
> ON UPDATE NO ACTION ON DELETE NO ACTION;' - Strange shift and
> strip last char in 'ssss' - displayed as 'sss'
Fixed in SVN.
Thanks, Dave.
On 12 Oct 2007, at 17:03, Dave Page wrote:
<color><param>7F00,0000,0000</param>> > 1. Need retrieve fresh copy of function/trigger function
(especially
> > trigger function, each have 2 local copy in PgAdmin DB
presentation
> > tree) from server before allow editing - for avoid too annoying
> > message that you see at end editing about old/expired/nonfresh
> > edition of (trigger) function plus chance edit expired function.
>
> Yeah, unfortunately there's no infrastructure to link the two
objects
> together at the moment. This was discussed a month or so back.
</color>I speak only about retrieve fresh copy of function body before
editing regardless any infrastructure. In other words: before
processing 'Properties' at function simulate 'Refresh'
<color><param>7F00,0000,0000</param>> > 4. Something wrong with 'Limit bar' and 'Database bar' - see
garbage
> > under bar during movement left-right
>
> I see a tiny drawing artifact. That's wxWidgets though I believe.
</color>Possible exist way found source of this artifacts?
<color><param>7F00,0000,0000</param>>
> > 5. Window with already edited function body still no question
close
> > in case press 'ESC' :-(
>
> We don't ever query the user if a dialogue is cancelled.
From user point it is not simple dialog, this is edit function plus
during editing PgAdmin track (highlight 'Apply') change function body.
If difficult open 'Yes/no' windows in case already edited body
possible simple ignore 'ESC' with (optional) 'Beep'.
>
> > 6. No way determine stripped (partially displayed) or not value in
> > grid result table ('Output pane'->'Data Output') of 'Query'
window,
> > for instance try see field name 'i8' type 'bigint' with value
> > '12345678901234567890'. Possible exist reason change 'autoadjust'
> > field width to old behavior (max field value width) or use
> > shift/ctrl sense double click for select behavior.
>
> I don't understand the problem. 12345678901234567890 is out of range
> for a bigint so should never be returned as one. Please provide a
self
> contained test case to illustrate the problem.
</color>Sorry. '<color><param>7F00,0000,0000</param>12345678901234567890' should by '1234567890123456789' for
sample only.</color>
I speak about partially visible (or not) field value.
--------------------
Crash again.
Version 1.8.0 RC1 (Oct 9 2007, rev: 6725)
The instruction at "0x0058b778" referenced memory at "0x031cc018".
The memory could not be "read".
During expanding DB tree in multi DB servers environment.
Best regards,
Alexander Kirpa
Alexander Kirpa wrote: >> I don't understand the problem. 12345678901234567890 is out of range >> for a bigint so should never be returned as one. Please provide a self >> contained test case to illustrate the problem. > Sorry. '12345678901234567890' should by '1234567890123456789' for sample > only. > I speak about partially visible (or not) field value. Oh, you mean the column width? We don't attempt to auto-size the columns at all, though you can double click a header to make that happen. Any changes to that code will have to wait until the next development cycle. > -------------------- > Crash again. > > Version 1.8.0 RC1 (Oct 9 2007, rev: 6725) > The instruction at "0x0058b778" referenced memory at "0x031cc018". The > memory could not be "read". > > During expanding DB tree in multi DB servers environment. I can't reproduce this here in SVN trunk, though I did fix a bug that could easily have caused that a couple of days back. Do you have the 'View System Objects' option turned on so that template0 is visible? Regards, Dave
On 15 Oct 2007, at 9:58, Dave Page wrote: > Alexander Kirpa wrote: > > -------------------- > > Crash again. > > > > Version 1.8.0 RC1 (Oct 9 2007, rev: 6725) > > The instruction at "0x0058b778" referenced memory at "0x031cc018". > > The memory could not be "read". > > > > During expanding DB tree in multi DB servers environment. > > I can't reproduce this here in SVN trunk, though I did fix a bug that > could easily have caused that a couple of days back. Do you have the > 'View System Objects' option turned on so that template0 is visible? Yes. 'View System Objects' - always ON. See additional crash info reference: Version 1.8.0 RC1 (Oct 9 2007, rev: 6725) The instruction at "0x0058b778" referenced memory at "0x02cae010". The memory could not be "read". > > Regards, Dave Best regards,Alexander Kirpa
Alexander Kirpa wrote: > On 15 Oct 2007, at 9:58, Dave Page wrote: > >> Alexander Kirpa wrote: >>> -------------------- >>> Crash again. >>> >>> Version 1.8.0 RC1 (Oct 9 2007, rev: 6725) >>> The instruction at "0x0058b778" referenced memory at "0x031cc018". >>> The memory could not be "read". >>> >>> During expanding DB tree in multi DB servers environment. >> I can't reproduce this here in SVN trunk, though I did fix a bug that >> could easily have caused that a couple of days back. Do you have the >> 'View System Objects' option turned on so that template0 is visible? > Yes. 'View System Objects' - always ON. > See additional crash info reference: > Version 1.8.0 RC1 (Oct 9 2007, rev: 6725) > The instruction at "0x0058b778" referenced memory at "0x02cae010". > The memory could not be "read". Could well be the problem. May I mail you a new .exe to test? Regards, Dave
[Please keep replies on-list] Alexander Kirpa wrote: >> Is this reproducable? Can you provide a test case? > No, but this is 100% is not hardware problem. I'm not saying it is, but unfortunately these things are virtually impossible to fix if they cannot be reproduced. With thousands of lines of code in the query tool alone, tracking down an extremely rare and un-reproducable crash is nigh-on impossible. > I believe that this > problem similar to grid editor problem - in other word cumulative > effect after long-long edition w/o closing editor window. I doubt it. That was a problem in the data cache for new rows. There isn't anything like that in the query tool. > In addition some suggestion about 'Types', especially 'System type'. > Possible exist reason for 'System type' need have separate place in > tree. > In my case more 100 'System type' etc. plus > only approx. 10 real 'Types' that too hide within 'System Types' System types live under the Catalogs node. What you are probably seeing is types created by contrib modules in the public schema. Regards, Dave.
On 18 Oct 2007, at 12:04, Dave Page wrote: > Alexander Kirpa wrote: > In addition some suggestion about 'Types', especially 'System type'. > > Possible exist reason for 'System type' need have separate place in > > tree. In my case more 100 'System type' etc. plus only approx. 10 > > real 'Types' that too hide within 'System Types' > > System types live under the Catalogs node. What you are probably > seeing is types created by contrib modules in the public schema. Please try on empty DB with 'Show System Objects in the treeview': CREATE TABLE i2(i2 smallint NOT NULL,CONSTRAINT i2_pk PRIMARY KEY (i2)); and see "system" type 'i2' in 'Types' In case 100-200 tables DB with 5-10 "user" 'Types' - "system" 'Types' only waste space and hide important "user" types plus hints for "system" type wrong: 1. Impossible DROP and/or MODIFY 'System Types' 2. Impossible change owner of 'System Type' over 'Properties' Possible solution: a) Separate branch under 'Schemas'->(public)->'System Types'/'Table Types' or b) Separate branch under appropriate table 'Schemas'->(public)- >'Tables'->(i2)->'Types' Best regards,Alexander Kirpa > > Regards, Dave. > > Best regards,Alexander Kirpa
Alexander Kirpa wrote: > On 18 Oct 2007, at 12:04, Dave Page wrote: > >> Alexander Kirpa wrote: >> In addition some suggestion about 'Types', especially 'System type'. >>> Possible exist reason for 'System type' need have separate place in >>> tree. In my case more 100 'System type' etc. plus only approx. 10 >>> real 'Types' that too hide within 'System Types' >> System types live under the Catalogs node. What you are probably >> seeing is types created by contrib modules in the public schema. > Please try on empty DB with 'Show System Objects in the treeview': > CREATE TABLE i2(i2 smallint NOT NULL,CONSTRAINT i2_pk PRIMARY KEY > (i2)); > > and see "system" type 'i2' in 'Types' > > In case 100-200 tables DB with 5-10 "user" 'Types' - "system" 'Types' > only waste space and hide important "user" types plus hints for > "system" type wrong: > 1. Impossible DROP and/or MODIFY 'System Types' > 2. Impossible change owner of 'System Type' over 'Properties' > > Possible solution: > a) Separate branch under 'Schemas'->(public)->'System Types'/'Table > Types' or > b) Separate branch under appropriate table 'Schemas'->(public)- >> 'Tables'->(i2)->'Types' They aren't systems types - as you note they're table types. They're shown (like, for example, the sequences created for serial columns), because there may be legitimate uses for them, such as creating functions that return them. Regards, Dave