From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id F28D713877A for ; Sun, 3 Aug 2014 21:10:56 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 2B5EDE0838; Sun, 3 Aug 2014 21:10:51 +0000 (UTC) Received: from smtpq5.tb.mail.iss.as9143.net (smtpq5.tb.mail.iss.as9143.net [212.54.42.168]) by pigeon.gentoo.org (Postfix) with ESMTP id 12185E0804 for ; Sun, 3 Aug 2014 21:10:49 +0000 (UTC) Received: from [212.54.42.134] (helo=smtp3.tb.mail.iss.as9143.net) by smtpq5.tb.mail.iss.as9143.net with esmtp (Exim 4.76) (envelope-from ) id 1XE33J-0002D6-5E for gentoo-user@lists.gentoo.org; Sun, 03 Aug 2014 23:10:49 +0200 Received: from 53579160.cm-6-8c.dynamic.ziggo.nl ([83.87.145.96] helo=data.antarean.org) by smtp3.tb.mail.iss.as9143.net with esmtp (Exim 4.76) (envelope-from ) id 1XE33I-0008Nj-SL for gentoo-user@lists.gentoo.org; Sun, 03 Aug 2014 23:10:49 +0200 Received: from andromeda.localnet (unknown [10.20.13.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by data.antarean.org (Postfix) with ESMTPSA id D767E4C for ; Sun, 3 Aug 2014 23:10:20 +0200 (CEST) From: "J. Roeleveld" To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] Re: Recommendations for scheduler Date: Sun, 03 Aug 2014 23:10:44 +0200 Message-ID: <28718389.0BGicRObMX@andromeda> Organization: Antarean User-Agent: KMail/4.12.5 (Linux/3.14.14-gentoo; KDE/4.12.5; x86_64; ; ) In-Reply-To: <53DEA222.9000200@gmail.com> References: <53DBCF34.6060601@gmail.com> <1411975.aGe8I0iaLa@andromeda> <53DEA222.9000200@gmail.com> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Ziggo-spambar: ---- X-Ziggo-spamscore: -4.9 X-Ziggo-spamreport: ALL_TRUSTED=-1,BAYES_00=-1.9,PROLO_TRUST_RDNS=-3,RDNS_DYNAMIC=0.982 X-Ziggo-Spam-Status: No X-Spam-Status: No X-Spam-Flag: No X-Archives-Salt: 8c0e3f48-797a-462b-8142-1d4acfe6367b X-Archives-Hash: cbf50c0a4023c36422563fbedd78b540 On Sunday, August 03, 2014 10:57:06 PM Alan McKinnon wrote: > On 03/08/2014 22:23, J. Roeleveld wrote: > > On Sunday, August 03, 2014 10:04:50 PM Alan McKinnon wrote: > >> On 03/08/2014 15:36, J. Roeleveld wrote: > >>>> Maybe this "protocol" is not the most clever solution, but it is > >>>> > >>>>> one which could be implemented without lots of overhead: > >>>>> Mainly, I was up to a "quick" solution which is working good enough > >>>>> for me: If the server has no bugs, why should it die? > >>>>> Moreover, if the server dies for some strange reasons, it is probably > >>>>> safer to re-queue the jobs again, anyway. > >>> > >>> With the kind of schedules I am working with (and I believe Alan will > >>> also > >>> end up with), restarting the whole process from the start can lead to > >>> issues. Finding out how far the process got before the service crashed > >>> can become rather complex. > >> > >> Yes, very much so. My first concern is the database cleanups - without > >> scheduler guarantees I'd need transactions in MySQL. > > > > Or you migrate to PostgreSQL, but that is OT :) > > Maybe, but also valid :-) > > I took one look at the schemas here and wondered "Why MySQL? This is > Postgres territory". It's a case of LAMP tunnel vision. That and that people who start with LAMP don't learn SQL. This leads to code that is near impossible to port to a different database and when people actually want to do all the work to get the SQL to work on any database, the projects involved refuse the patches. -- Joost