Thread: Crash on delete record with filter in place
Using pgadmin 1.15 Dev on Opensuse 11.4, kernel 3.0. Viewing the data in a table with full data set visible, select a record for delete, run delete, record is deleted correctly, pgadmin continues to run. View the data in a table and place a filter to show subset of records. Attempt to delete a row. This is permitted by the menus. Row is deleted correctly, however pgadmin immediately crashes both the main and the view data windows. Data is intact, restarting pgadmin allows to continue as before. -- --- Colin Beckingham 613-454-5369 http://www.it4gh.com
On Sat, 2011-09-17 at 17:45 -0400, Colin Beckingham wrote: > Using pgadmin 1.15 Dev on Opensuse 11.4, kernel 3.0. > > Viewing the data in a table with full data set visible, select a record > for delete, run delete, record is deleted correctly, pgadmin continues > to run. > > View the data in a table and place a filter to show subset of records. > Attempt to delete a row. This is permitted by the menus. Row is deleted > correctly, however pgadmin immediately crashes both the main and the > view data windows. Data is intact, restarting pgadmin allows to continue > as before. I don't manage to get a reproducible test case. I mean, I do get some crashes, but they are mostly random. Something that would crash pgAdmin once won't work twice. Which doesn't help fixing it. -- Guillaume http://blog.guillaume.lelarge.info http://www.dalibo.com
<br /><br />On Monday, September 19, 2011, Guillaume Lelarge <<a href="mailto:guillaume@lelarge.info">guillaume@lelarge.info</a>>wrote:<br />> On Sat, 2011-09-17 at 17:45 -0400, ColinBeckingham wrote:<br />>> Using pgadmin 1.15 Dev on Opensuse 11.4, kernel 3.0.<br /> >><br />>> Viewingthe data in a table with full data set visible, select a record<br />>> for delete, run delete, record is deletedcorrectly, pgadmin continues<br />>> to run.<br />>><br />>> View the data in a table and placea filter to show subset of records.<br /> >> Attempt to delete a row. This is permitted by the menus. Row is deleted<br/>>> correctly, however pgadmin immediately crashes both the main and the<br />>> view data windows.Data is intact, restarting pgadmin allows to continue<br /> >> as before.<br />><br />> I don't manageto get a reproducible test case. I mean, I do get some<br />> crashes, but they are mostly random. Something thatwould crash pgAdmin<br />> once won't work twice. Which doesn't help fixing it.<br /><br />Random crashes should certainlybe investigated though, especially if you've found an area of the code where they may happen from time to time.Can you attempt to reproduce with core dump enabled, or even under GDB? I'd like to see a backtrace if possible.<br/><br />FYI, I fixed a crash bug this morning that conceivably could occur anywhere, but in practice was onlyreproducible on some Solaris boxes. <br /><br />-- <br />Dave Page<br />Blog: <a href="http://pgsnake.blogspot.com" target="_blank">http://pgsnake.blogspot.com</a><br/> Twitter: @pgsnake<br /><br />EnterpriseDB UK: <a href="http://www.enterprisedb.com"target="_blank">http://www.enterprisedb.com</a><br />The Enterprise PostgreSQL Company<br/><br />
On Mon, 2011-09-19 at 14:23 -0500, Dave Page wrote:
> On Monday, September 19, 2011, Guillaume Lelarge <guillaume@lelarge.info>
> wrote:
> > On Sat, 2011-09-17 at 17:45 -0400, Colin Beckingham wrote:
> >> Using pgadmin 1.15 Dev on Opensuse 11.4, kernel 3.0.
> >>
> >> Viewing the data in a table with full data set visible, select a record
> >> for delete, run delete, record is deleted correctly, pgadmin continues
> >> to run.
> >>
> >> View the data in a table and place a filter to show subset of records.
> >> Attempt to delete a row. This is permitted by the menus. Row is deleted
> >> correctly, however pgadmin immediately crashes both the main and the
> >> view data windows. Data is intact, restarting pgadmin allows to continue
> >> as before.
> >
> > I don't manage to get a reproducible test case. I mean, I do get some
> > crashes, but they are mostly random. Something that would crash pgAdmin
> > once won't work twice. Which doesn't help fixing it.
>
> Random crashes should certainly be investigated though, especially if you've
> found an area of the code where they may happen from time to time. Can you
> attempt to reproduce with core dump enabled, or even under GDB? I'd like to
> see a backtrace if possible.
>
See the attachment. I was using GDB. Note that this is not a segfault.
It's a SIGABRT.
What surprised me at first was this:
#6 0x00007ffff7148ef5 in wxGrid::SetTable (this=0x1b48a10, table=0x0,
takeOwnership=false, selmode=wxGrid::wxGridSelectCells)
at ./src/generic/grid.cpp:4529
I first suspected that it was due to the "refresh-on-click" patch. But
it doesn't seem so.
> FYI, I fixed a crash bug this morning that conceivably could occur anywhere,
> but in practice was only reproducible on some Solaris boxes.
>
Yeah, saw that. Good catch.
--
Guillaume
http://blog.guillaume.lelarge.info
http://www.dalibo.com
Attachment
On 09/19/2011 03:12 PM, Guillaume Lelarge wrote: > On Sat, 2011-09-17 at 17:45 -0400, Colin Beckingham wrote: >> Using pgadmin 1.15 Dev on Opensuse 11.4, kernel 3.0. >> >> Viewing the data in a table with full data set visible, select a record >> for delete, run delete, record is deleted correctly, pgadmin continues >> to run. >> >> View the data in a table and place a filter to show subset of records. >> Attempt to delete a row. This is permitted by the menus. Row is deleted >> correctly, however pgadmin immediately crashes both the main and the >> view data windows. Data is intact, restarting pgadmin allows to continue >> as before. > > I don't manage to get a reproducible test case. I mean, I do get some > crashes, but they are mostly random. Something that would crash pgAdmin > once won't work twice. Which doesn't help fixing it. > > Well, so far 1.15 has been working well for me. This incident (which I managed to repeat several times) was the only time it has let me down. I tried setting up a simple table to repeat the issue I reported but I admit I failed to repeat it. On my small test table with oids in place I was able to delete records with no filter in place or with a filter. It worked fine. I am reluctant to attempt a repeat the crash with my other table which is important right now - I will try to recreate the crash on a copy later. This other table is much larger and more complex. In my investigation I did seem to find that tables with oids in place allowed me to delete a record via the toolbar icon, but the right click contextual submenu items remained greyed out. Table without oids on select a record or set of records does not activate the delete records icon on the toolbar or in the contextual submenu. An exception to the observation on context submenu in the last para. If the data is entered through the insert script, and then you open the view data - view all rows, the context menu does not work. However if you enter data _into_ the view data table this then activates the context menu and you can delete. More later. -- --- Colin Beckingham
On Mon, Sep 19, 2011 at 8:34 PM, Guillaume Lelarge <guillaume@lelarge.info> wrote: > > See the attachment. I was using GDB. Note that this is not a segfault. > It's a SIGABRT. > > What surprised me at first was this: > > #6 0x00007ffff7148ef5 in wxGrid::SetTable (this=0x1b48a10, table=0x0, > takeOwnership=false, selmode=wxGrid::wxGridSelectCells) > at ./src/generic/grid.cpp:4529 > > I first suspected that it was due to the "refresh-on-click" patch. But > it doesn't seem so. Do you recall what you did to produce this (and what you did beforehand in that window)? -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On 09/19/2011 04:53 PM, Colin Beckingham wrote: > > > On 09/19/2011 03:12 PM, Guillaume Lelarge wrote: >> On Sat, 2011-09-17 at 17:45 -0400, Colin Beckingham wrote: >>> Using pgadmin 1.15 Dev on Opensuse 11.4, kernel 3.0. >>> >>> Viewing the data in a table with full data set visible, select a record >>> for delete, run delete, record is deleted correctly, pgadmin continues >>> to run. >>> >>> View the data in a table and place a filter to show subset of records. >>> Attempt to delete a row. This is permitted by the menus. Row is deleted >>> correctly, however pgadmin immediately crashes both the main and the >>> view data windows. Data is intact, restarting pgadmin allows to continue >>> as before. >> >> I don't manage to get a reproducible test case. I mean, I do get some >> crashes, but they are mostly random. Something that would crash pgAdmin >> once won't work twice. Which doesn't help fixing it. >> >> > > Well, so far 1.15 has been working well for me. This incident (which I > managed to repeat several times) was the only time it has let me down. > > I tried setting up a simple table to repeat the issue I reported but I > admit I failed to repeat it. On my small test table with oids in place I > was able to delete records with no filter in place or with a filter. It > worked fine. > > I am reluctant to attempt a repeat the crash with my other table which > is important right now - I will try to recreate the crash on a copy > later. This other table is much larger and more complex. > > In my investigation I did seem to find that tables with oids in place > allowed me to delete a record via the toolbar icon, but the right click > contextual submenu items remained greyed out. Table without oids on > select a record or set of records does not activate the delete records > icon on the toolbar or in the contextual submenu. > > An exception to the observation on context submenu in the last para. If > the data is entered through the insert script, and then you open the > view data - view all rows, the context menu does not work. However if > you enter data _into_ the view data table this then activates the > context menu and you can delete. > > More later. Oki doki, some more information for you. I have repeated the error, it is now crashing with no filter in place. Short feedback: gdb says:Program received signal SIGSEGV, Segmentation fault. 0x00007ffff70b34a7 in wxGridCellAttrData::UpdateAttrRows(unsigned long, int) () from /usr/lib64/wx-2.8-wxcontainer/libwx_gtk2u_adv-2.8.so.0 Long feedback: 1. using a table with 10,000+ records, with oids, with serial field, and about 5 other numeric and text fields. I can send you the entire copy version if you would like it 2. no external relations or indexes involved apart from the serial field 3. go into view data, select a record, toolbar icon lights up 4. click toolbar icon, record disappears and pgadmin goes with it. -- --- Colin Beckingham 613-454-5369 http://www.it4gh.com
On Tue, 2011-09-20 at 13:21 +0100, Dave Page wrote: > On Mon, Sep 19, 2011 at 8:34 PM, Guillaume Lelarge > <guillaume@lelarge.info> wrote: > > > > See the attachment. I was using GDB. Note that this is not a segfault. > > It's a SIGABRT. > > > > What surprised me at first was this: > > > > #6 0x00007ffff7148ef5 in wxGrid::SetTable (this=0x1b48a10, table=0x0, > > takeOwnership=false, selmode=wxGrid::wxGridSelectCells) > > at ./src/generic/grid.cpp:4529 > > > > I first suspected that it was due to the "refresh-on-click" patch. But > > it doesn't seem so. > > Do you recall what you did to produce this (and what you did > beforehand in that window)? > Nope, but here is another complete example. Create a new database. Restore colin.dump in it (it's a 9.1 custom dump which will create a table, add 10k lines, and then create an index). Then, open the database with pgadmin, select the table t1, and click on the "edit data" tool. Then, click on a line (I did it on the line 6 or 7). Crash more or less immediately. See the backtrace attached. -- Guillaume http://blog.guillaume.lelarge.info http://www.dalibo.com
Attachment
On Tue, 2011-09-20 at 10:48 -0400, Colin Beckingham wrote: > On 09/19/2011 04:53 PM, Colin Beckingham wrote: > > > > > > On 09/19/2011 03:12 PM, Guillaume Lelarge wrote: > >> On Sat, 2011-09-17 at 17:45 -0400, Colin Beckingham wrote: > >>> Using pgadmin 1.15 Dev on Opensuse 11.4, kernel 3.0. > >>> > >>> Viewing the data in a table with full data set visible, select a record > >>> for delete, run delete, record is deleted correctly, pgadmin continues > >>> to run. > >>> > >>> View the data in a table and place a filter to show subset of records. > >>> Attempt to delete a row. This is permitted by the menus. Row is deleted > >>> correctly, however pgadmin immediately crashes both the main and the > >>> view data windows. Data is intact, restarting pgadmin allows to continue > >>> as before. > >> > >> I don't manage to get a reproducible test case. I mean, I do get some > >> crashes, but they are mostly random. Something that would crash pgAdmin > >> once won't work twice. Which doesn't help fixing it. > >> > >> > > > > Well, so far 1.15 has been working well for me. This incident (which I > > managed to repeat several times) was the only time it has let me down. > > > > I tried setting up a simple table to repeat the issue I reported but I > > admit I failed to repeat it. On my small test table with oids in place I > > was able to delete records with no filter in place or with a filter. It > > worked fine. > > > > I am reluctant to attempt a repeat the crash with my other table which > > is important right now - I will try to recreate the crash on a copy > > later. This other table is much larger and more complex. > > > > In my investigation I did seem to find that tables with oids in place > > allowed me to delete a record via the toolbar icon, but the right click > > contextual submenu items remained greyed out. Table without oids on > > select a record or set of records does not activate the delete records > > icon on the toolbar or in the contextual submenu. > > > > An exception to the observation on context submenu in the last para. If > > the data is entered through the insert script, and then you open the > > view data - view all rows, the context menu does not work. However if > > you enter data _into_ the view data table this then activates the > > context menu and you can delete. > > > > More later. > > Oki doki, some more information for you. > > I have repeated the error, it is now crashing with no filter in place. > It does so with me too. > Short feedback: > gdb says: > Program received signal SIGSEGV, Segmentation fault. > 0x00007ffff70b34a7 in wxGridCellAttrData::UpdateAttrRows(unsigned long, > int) () > from /usr/lib64/wx-2.8-wxcontainer/libwx_gtk2u_adv-2.8.so.0 > > Long feedback: > 1. using a table with 10,000+ records, with oids, with serial field, and > about 5 other numeric and text fields. I can send you the entire copy > version if you would like it > 2. no external relations or indexes involved apart from the serial field > 3. go into view data, select a record, toolbar icon lights up > 4. click toolbar icon, record disappears and pgadmin goes with it. > Well, I don't think we need the whole definition. It already crashes with a one-column table. But thanks for the info :) -- Guillaume http://blog.guillaume.lelarge.info http://www.dalibo.com
<div class="WordSection1"><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Isthere a reason why either pgAdmin or postgresqlitself can not use the following method for doing column width changes:</span><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><pclass="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><a href="http://sniptools.com/databases/resize-a-column-in-a-postgresql-table-without-changing-data">http://sniptools.com/databases/resize-a-column-in-a-postgresql-table-without-changing-data</a></span><p class="MsoNormal"><spanstyle="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><p class="MsoNormal"><spanstyle="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">particularly in the casewhere the column is used in views etc, unless there is a down-side to using this approach?</span><p class="MsoNormal"><spanstyle="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><p class="MsoNormal"><spanstyle="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Regards,</span><p class="MsoNormal"><spanstyle="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Peter.</span><p class="MsoNormal"><spanstyle="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span></div>
On Tue, Sep 20, 2011 at 8:52 PM, Guillaume Lelarge <guillaume@lelarge.info> wrote: > On Tue, 2011-09-20 at 13:21 +0100, Dave Page wrote: >> On Mon, Sep 19, 2011 at 8:34 PM, Guillaume Lelarge >> <guillaume@lelarge.info> wrote: >> > >> > See the attachment. I was using GDB. Note that this is not a segfault. >> > It's a SIGABRT. >> > >> > What surprised me at first was this: >> > >> > #6 0x00007ffff7148ef5 in wxGrid::SetTable (this=0x1b48a10, table=0x0, >> > takeOwnership=false, selmode=wxGrid::wxGridSelectCells) >> > at ./src/generic/grid.cpp:4529 >> > >> > I first suspected that it was due to the "refresh-on-click" patch. But >> > it doesn't seem so. >> >> Do you recall what you did to produce this (and what you did >> beforehand in that window)? >> > > Nope, but here is another complete example. > > Create a new database. Restore colin.dump in it (it's a 9.1 custom dump > which will create a table, add 10k lines, and then create an index). > Then, open the database with pgadmin, select the table t1, and click on > the "edit data" tool. Then, click on a line (I did it on the line 6 or > 7). Crash more or less immediately. See the backtrace attached. I cannot reproduce on Windows, Mac or Linux :-( -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On Wed, 2011-09-21 at 14:17 +0100, Dave Page wrote: > On Tue, Sep 20, 2011 at 8:52 PM, Guillaume Lelarge > <guillaume@lelarge.info> wrote: > > On Tue, 2011-09-20 at 13:21 +0100, Dave Page wrote: > >> On Mon, Sep 19, 2011 at 8:34 PM, Guillaume Lelarge > >> <guillaume@lelarge.info> wrote: > >> > > >> > See the attachment. I was using GDB. Note that this is not a segfault. > >> > It's a SIGABRT. > >> > > >> > What surprised me at first was this: > >> > > >> > #6 0x00007ffff7148ef5 in wxGrid::SetTable (this=0x1b48a10, table=0x0, > >> > takeOwnership=false, selmode=wxGrid::wxGridSelectCells) > >> > at ./src/generic/grid.cpp:4529 > >> > > >> > I first suspected that it was due to the "refresh-on-click" patch. But > >> > it doesn't seem so. > >> > >> Do you recall what you did to produce this (and what you did > >> beforehand in that window)? > >> > > > > Nope, but here is another complete example. > > > > Create a new database. Restore colin.dump in it (it's a 9.1 custom dump > > which will create a table, add 10k lines, and then create an index). > > Then, open the database with pgadmin, select the table t1, and click on > > the "edit data" tool. Then, click on a line (I did it on the line 6 or > > 7). Crash more or less immediately. See the backtrace attached. > > I cannot reproduce on Windows, Mac or Linux :-( > I didn't try on Windows or Mac. But I still trigger it on Linux. -- Guillaume http://blog.guillaume.lelarge.info http://www.dalibo.com
On Tue, 2011-09-20 at 09:13 -0500, Belbin, Peter wrote: > Is there a reason why either pgAdmin or postgresql itself can not use the following method for doing column width changes: > > http://sniptools.com/databases/resize-a-column-in-a-postgresql-table-without-changing-data > > particularly in the case where the column is used in views etc, unless there is a down-side to using this approach? > I guess it may have some bad corner cases with cached plans and things like that. Why we don't do it in pgAdmin is quite simple: 1. nobody cares enough to write a patch for this 2. even if someone does, I don't feel comfortable commiting such a patch. I don't feel ready to commit such a patch because we have no guarantee it'll work. It may work now and then (and only if you keep the same datatype, but add more characters), but it's not guaranteed, hence the fact that Tom asks the OP to do it in a transaction, to rollback in case of trouble). So, in a few words, too risky. -- Guillaume http://blog.guillaume.lelarge.info http://www.dalibo.com