Bugs item #2154236, was opened at 2008-10-09 04:39 Message generated for change (Settings changed) made by stmane You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=482468&aid=2154236&group_id=56967
Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core Group: MonetDB5 CVS Head Status: Closed >Resolution: Invalid Priority: 5 Private: No Submitted By: Stefan de Konink (skinkie) Assigned to: Nobody/Anonymous (nobody) Summary: On server crash last added table was lost Initial Comment: I was checking out my previous bug. That is still creating a segmentation fault. But I am very surprised that with this segmentation fault my complete (just inserted) table was lost. ...trivial to add. But I could do better things with my time. ---------------------------------------------------------------------- Comment By: Martin Kersten (mlkersten) Date: 2008-11-09 21:53 Message: Given the remarks made at 2008-10-20 I consider this bug as being closed. There is not enough information to re-construct the errors and cast it into a nightly test. ---------------------------------------------------------------------- Comment By: Stefan Manegold (stmane) Date: 2008-10-20 23:59 Message: Yes, database systems do allow more than one transaction; hence, there can be non-committed changes in a (not yet committed) transaction that follows a previous committed or aborted transaction. ---------------------------------------------------------------------- Comment By: Stefan de Konink (skinkie) Date: 2008-10-20 23:45 Message: If I recall correctly I already did a query after using copy into. Do I understand your comment right that there is actually possibility that there are non committed changes *after* a transaction took place? (Hence the insert was finished, otherwise I couldn't do my crashing query.) The trashing query doesn't crash anymore, it is nicely handled, so I hope more code improvements have been made to prevent dataloss. ---------------------------------------------------------------------- Comment By: Stefan Manegold (stmane) Date: 2008-10-20 20:26 Message: Transaction semantics demand that non-committed changes have no effect if the transaction is aborted (e.g.) due to a crash. ---------------------------------------------------------------------- Comment By: Stefan de Konink (skinkie) Date: 2008-10-20 12:08 Message: I'm sorry, I'm not going to add more comments if you cannot parse basic English text and solve bugs by making them 'by design' and fix documentation accordingly. If you cannot interpreted table lost after segmentation fault I clearly doubt the willingness to fix the problem in the first place. It doesn't really matter what exactly I am doing if there is no signal handler that actually makes sure the data is safe. ---------------------------------------------------------------------- Comment By: Sjoerd Mullender (sjoerd) Date: 2008-10-20 11:01 Message: Details, details. How on earth do you think we can ever hope to fix any bugs when you don't provide even the merest hint of what you were doing and what happened. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=482468&aid=2154236&group_id=56967 ------------------------------------------------------------------------------ Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H _______________________________________________ Monetdb-bugs mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/monetdb-bugs
