[csw-maintainers] [csw-buildfarm] Building postgresql-8.4.1

[Dagobert Michelsen]

Hi Maciej,

Am 02.12.2009 um 15:35 schrieb Maciej (Matchek) Blizinski:
> On Mon, Nov 30, 2009 at 10:27 AM, Dagobert Michelsen  
> <dam at opencsw.org> wrote:
>> Hi Maciej,
>
>>> On build8s the tests pass just fine.  Is it something that buildfarm
>>> admins can fix?
>>
>> Yes. I need to turn up SHMMAX on build8x and reboot. As I plan to  
>> migrate
>> that
>> on the VMware farm I can just install the new one for you to test.  
>> Please
>> allow
>> me some more time to finish it.
>
> Sure. Please let me know when it's done.  I'll build the Intel
> architecture packages then.
>
> Meanwhile, I'd like to continue the 32/64 bit PostgreSQL discussion.
> My intuition is that application should run the native architecture
> binaries, unless there's a reason to do otherwise.  Dago wrote, that
> it makes sense to do run 64-bit binaries (where possible) by default,
> when:
>
>> (1) using the proper width is mandatory (e.g. /dev/kmem access)
>> (2) using 64 bit always has an advantage
>> (3) there is difference in output between 32/64 bit
>
> I don't agree with the second point, because it's phrased too
> strongly.  64-bit will not always be advantageous, because you can
> find such data and such criteria that 32-bit binary will do better.
>
> I understand that for many applications there's no advantage in
> running in 64-bit width, and therefore the main policy is "use 32 bit
> only unless there are reasons to use 64-bit".  In the case of a
> database engine, there is one general reason to use 64-bit width:
> databases tend to be big and run on big machines, using way more than
> just 2GB of RAM.  Defaulting to 32-bit is like setting up a trap.
>
> I understand that the two main arguments against using 64-bit by
> default where possible are:
>
> - it consumes more memory
> - it potentially runs slower
>
> I've got a Netra T1125 2X 440MHZ to experiment with.  I've run pgbench
> using sparcv8 and sparcv9 binaries.
>
> sparcv8
> tps = 22.976848 (including connections establishing)
> tps = 23.070799 (excluding connections establishing)
>
> sparcv9:
> tps = 25.318832 (including connections establishing)
> tps = 25.481666 (excluding connections establishing)
>
> I also know that Dago didn't want to use isaexec, because somebody
> might want to copy raw data directories between 32- and 64-bit
> architecture machines.  I agree that it might happen, but as far as my
> database experience goes, messing with raw data directories is
> generally asking for trouble.  The way to get the data to or out of a
> database is via database dumps, which are architecture independent.
> If somebody wants replication, they should use slony.
>
> We could have a postinstall script which would detect and set the
> architecture, but isn't it what isaexec does anyway?

Yes, but on every invocation. You can execute the postinstall selecting
32/64 bit with isaexec for optimal selection, but the selection should
be static and not be changed between invocations of the database.

> One more thing: using isaexec doesn't take the choice away.  The user
> can still set the path to the exact binary and run 32 or 64-bit
> version specifically, if they want to.
>
> To sum up:  I maintain that it's best to:
>
> 1. Use native architecture width by default
> 2. Give the user the choice if they have a preference this or the  
> other way
>
> isaexec does both those things.
>
> There's another way of doing it: Force the user to choose the
> architecture before they can run PostgreSQL at all.  I think it would
> be a user-repellent policy.  It's so much nicer when the package runs
> out of the box:
>
> pkgutil -y -i postgresql
> sudo -u postgres createuser joe
> createdb joe
> psql
>
> The negative impact of the database not working out of the box would
> in my opinion by greater than the positive impact of being always
> conscious about whether it's possible to copy the data files between
> machines with different bit width architectures.
>
> If people want to, I can draw another table with pros and cons.

For me you can just default to 64 bit as almost all systems support it
and as you said the advantage is there.


Best regards

   -- Dago