Bug#696138: [Pkg-postgresql-public] Bug#696138: Increase pg_ctlcluster on slow architectures
Martin Pitt dixit: Christoph Berg [2012-12-19 10:40 +0100]: We could probably wait for the startup, but then exit 0 with the message cluster is still starting up. I like that idea. It should avoid postinst failures on slow architectures, but in the normal case a /etc/init.d/postgresql restart should still wait until your cluster is ready to be used. I think this does not work. One use case here is a buildd that tries to build something that is a PostgreSQL client, which then runs a DB server during its testsuite. I really think that the initscript needs to wait here, possibly pretty long (DB recovery was already mentioned) – after all, pgsql comes from BSD land “better slow than unsafe”. bye, //mirabilos -- 21:27⎜[Natureshadow] BÄH! Wer hatn das Bier neben den Notebooklüfter ⎜gestellt ... Das ist ja warm! 21:27⎜Natureshadow lol 21:27⎜Natureshadow du? 21:27⎜[Natureshadow] vermutlich ... -- Kev^WNatureshadow allein zu Haus -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#696138: Increase pg_ctlcluster on slow architectures
Re: Martin Pitt 2012-12-17 20121217070817.gb2...@piware.de Package: postgresql-common Version: 129 From IRC ping: [19:17:48] hi, while you're working on postgresql-common: is it possible for it to wait more than one minute on slow arches such as m68k, avr32, sh4, etc? This needs some thinking as I don't quite like a complex arch → timeout lookup table, but more than a minute is quite excessive on architectures which are realistically being used as a database server. Do we need to wait for a successful connect at all? If the cluster happens to be recovering, that could take an arbitrary amount of time. Wouldn't waiting for the pid file be enough? We could probably wait for the startup, but then exit 0 with the message cluster is still starting up. Christoph -- c...@df7cb.de | http://www.df7cb.de/ signature.asc Description: Digital signature
Bug#696138: [Pkg-postgresql-public] Bug#696138: Increase pg_ctlcluster on slow architectures
Christoph Berg [2012-12-19 10:40 +0100]: We could probably wait for the startup, but then exit 0 with the message cluster is still starting up. I like that idea. It should avoid postinst failures on slow architectures, but in the normal case a /etc/init.d/postgresql restart should still wait until your cluster is ready to be used. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature
Bug#696138: Increase pg_ctlcluster on slow architectures
Re: Martin Pitt 2012-12-19 20121219095452.gd3...@piware.de Christoph Berg [2012-12-19 10:40 +0100]: We could probably wait for the startup, but then exit 0 with the message cluster is still starting up. I like that idea. It should avoid postinst failures on slow architectures, but in the normal case a /etc/init.d/postgresql restart should still wait until your cluster is ready to be used. Bonus points for not waiting at all for a cluster that is configured for warm (not hot) standby. (Though that's probably not trivial to distinguish from a cluster that is set up for PITR on startup.) Christoph -- c...@df7cb.de | http://www.df7cb.de/ signature.asc Description: Digital signature
Bug#696138: Increase pg_ctlcluster on slow architectures
severity 696138 wishlist thanks Martin Pitt dixit: From IRC ping: Thanks for following up on this. [19:18:02] for example, on my box, the script timeouted just beforee the db came up successfully Actually, that was while doing a build in parallel, so it should probably finish within 45s or less on normal activity. This needs some thinking as I don't quite like a complex arch → timeout lookup table, but more than a minute is quite excessive on architectures which are realistically being used as a database server. Right, but this is not necessarily about being used as a database server. Sometimes, it’s about availability, or even installability, or just for testing purposes. Currently, an apt-get install can fail because the automatically generated main cluster doesn’t come up, even if it does. Instead of a complex lookup table, how about something like a positive list of architectures for which to take 1 minute, and 3 minutes for all others? Just increasing it to 2 minutes for all might be possible or not desirable, depending on your choices… probably about having fast(er) feedback. Hm. There *are* slow i386 boxen, too. How portable is something like this: root@aranym:~ # fgrep -i bogomips /proc/cpuinfo BogoMips: 191.89 Considering linux_logo parses that… possibly not too much. :( Apparently, parsing /proc/cpuinfo for bogomips/BogoMips/BogoMIPS is enough on all but SPARC which also does an fnmatch on Cpu[0-9]*Bogo* there; the remainder of the line appears to be the float value in all cases. (This from looking at the linuxlogo source code.) Where “all” are the Linux architectures alpha amd64 arm avr32 cris frv i386 ia64 m32r m68k microblaze mips parisc ppc s390 s390x sh3 sparc vax. On kfreebsd and hurd, it probably counts the delay loop itself… Then, there’s pystones. The default run of them is 10'000 times, which is a bit much for us. 100 runs is almost immediate even on m68k and could be used. Or maybe 500. 500 runs go through in a bit more than one second wallclock time on the example box, which is faster than many m68k boxen though. root@ara2:~ # python -c 'from test import pystone; pystone.main(100)' Pystone(1.1) time for 100 passes = 0.08 This machine benchmarks at 1250 pystones/second On the other hand, on a Celeron 2.4 GHz (those with 64K cache in total…) 100 runs gives nothing: tg@frozenfish:~ $ python -c 'from test import pystone; pystone.main(100)' Pystone(1.1) time for 100 passes = 0 This machine benchmarks at 0 pystones/second tg@frozenfish:~ $ python -c 'from test import pystone; pystone.main(500)' Pystone(1.1) time for 500 passes = 0.02 This machine benchmarks at 25000 pystones/second A 6200 bogomips amd64 machine is even worse: root@tglase-dev:~ # python -c 'from test import pystone; pystone.main(100)' Pystone(1.1) time for 100 passes = 0 This machine benchmarks at 0 pystones/second root@tglase-dev:~ # python -c 'from test import pystone; pystone.main(500)' Pystone(1.1) time for 500 passes = 0 This machine benchmarks at 0 pystones/second root@tglase-dev:~ # python -c 'from test import pystone; pystone.main(1000)' Pystone(1.1) time for 1000 passes = 0.01 This machine benchmarks at 10 pystones/second The time needed to run 1000 pystones is already very noticeable. One way could be to run the pystones once, at postinst time, and cache the result. Another way could be to try with 250 first (possibly not more than two seconds even on slower m68k and avr32) and then retry with 1 if the value read is 0 pystones/second. Then define a cutoff. Or just ignore this problem, which is also valid. I’ve lowered the severity. This may be something for when bored… bye, //mirabilos -- hecker cool ein Ada Lovelace Google-Doodle. aber zum 197. Geburtstag? Hätten die nicht noch 3 Jahre warten können? mirabilos bis dahin gibts google nicht mehr hecker ja, könnte man meinen. wahrscheinlich ist der angekündigte welt- untergang aus dem maya-kalender die globale abschaltung von google ☺ und darum müssen die die doodles vorher noch raushauen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#696138: Increase pg_ctlcluster on slow architectures
Package: postgresql-common Version: 129 From IRC ping: [19:17:48] hi, while you're working on postgresql-common: is it possible for it to wait more than one minute on slow arches such as m68k, avr32, sh4, etc? [19:18:02] for example, on my box, the script timeouted just beforee the db came up successfully [19:18:10] (akonadi-backend-postgresql FTW!) [19:18:17] and it's one of the faster m68k boxen This needs some thinking as I don't quite like a complex arch → timeout lookup table, but more than a minute is quite excessive on architectures which are realistically being used as a database server. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
