Thread: Crash on delete record with filter in place

Crash on delete record with filter in place

From
Colin Beckingham
Date:
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


Re: Crash on delete record with filter in place

From
Guillaume Lelarge
Date:
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



Re: Crash on delete record with filter in place

From
Dave Page
Date:
<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 /> 

Re: Crash on delete record with filter in place

From
Guillaume Lelarge
Date:
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

Re: Crash on delete record with filter in place

From
Colin Beckingham
Date:

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


Re: Crash on delete record with filter in place

From
Dave Page
Date:
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


Re: Crash on delete record with filter in place

From
Colin Beckingham
Date:
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


Re: Crash on delete record with filter in place

From
Guillaume Lelarge
Date:
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

Re: Crash on delete record with filter in place

From
Guillaume Lelarge
Date:
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



possible improvement for column resizing

From
"Belbin, Peter"
Date:
<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> 

Re: Crash on delete record with filter in place

From
Dave Page
Date:
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


Re: Crash on delete record with filter in place

From
Guillaume Lelarge
Date:
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



Re: possible improvement for column resizing

From
Guillaume Lelarge
Date:
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