Re:PostgreSQL benchmarks under giant lock free DragonflyBSD
by einhverfr on Wednesday February 22, 2012 @08:31AM
(#3620751)
I don't know that the issues reported can be called "crashes." Rather it is locking up, probably because there are not enough resources reserved for the terminal and therefore the terminal becomes unresponsive while waiting for an opportunity to run.
[ Parent
| on HN ]
Re:PostgreSQL benchmarks under giant lock free DragonflyBSD
by m_eiman on Wednesday February 22, 2012 @09:37AM
(#3620983)
It was also the less stable. I discovered more than once the machine was
completely frozen (blank screen, no keyboard or network response). Even a NMI
couldn't change anything.
Sounds like a rather hard crash to me.
Re:PostgreSQL benchmarks under giant lock free DragonflyBSD
by einhverfr on Thursday February 23, 2012 @08:52AM
(#3624900)
Not a hard crash because the computer eventually would recover on its own as load lightens up. It's just a matter of interactive tasks not getting the priority you want them to have.
Re:PostgreSQL benchmarks under giant lock free DragonflyBSD
by seclorum on Wednesday February 22, 2012 @11:04AM
(#3621345)
Were database transactions continuing while the terminal was non-responsive? Yes. Thus, its not really crashed.
Re:PostgreSQL benchmarks under giant lock free DragonflyBSD
by gaius on Wednesday February 22, 2012 @12:45PM
(#3621725)
Hmm. I remember back in the day, when the display driver could crash on an NT 3.51 box, but SQL Server would still be up. We treated that as a crash.
A machine that was not responding on the network is getting its database transactions from where exactly? It's crashed, even if the disks are still spinning.