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

severity 696138 wishlist
thanks

Martin Pitt dixit:

Thanks for following up on this.

Actually, that was while doing a build in parallel, so it should
probably finish within 45s or less on normal activity.

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 100000 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 10000
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

Re: Martin Pitt 2012-12-17 <20121217070817.GB2975@piware.de>

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

Christoph Berg [2012-12-19 10:40 +0100]:

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

Re: Martin Pitt 2012-12-19 <20121219095452.GD3019@piware.de>

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

Martin Pitt dixit:

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