[csw-maintainers] Building postgresql-8.4.1

[Dagobert Michelsen]

Hi Maciej,

Am 18.11.2009 um 11:17 schrieb Maciej (Matchek) Blizinski:
> On Wed, Nov 18, 2009 at 9:51 AM, Dagobert Michelsen  
> <dam at opencsw.org> wrote:
>> BTW: Make sure to read files/README-CSW.txt. It is stated in there
>> that the databases for 32 and 64 bit are not compatible, so I am  
>> pretty
>> sure you don't want isaexec anywhere in the package, but want to
>> select 32/64 explicitly as also stated in the README.
>
> I understand the incompatibility.  I don't understand why would it
> matter.  Machine's architecture doesn't change after installation.  If
> it's 64-bit, it's always been and always will be, until the machine is
> retired.
>
> There might be a problem when someone has been running 32-bit binaries
> on a 64-bit machine and now switches to the 64-bit enabled PostgreSQL.
> In such a they should downgrade their package back to the 32-bit and
> do the dump/restore dance.  However, if they upgrade from 8.3 to 8.4
> (which is the case here), they will have to do this anyway.  I also
> think that the PGCTL explicit setting is a non-solution.  It makes
> people run 32-bit binaries on 64-bit machines by default, which wastes
> the migration effort: they could've migrated from 32-bit 8.3 to 64-bit
> 8.4, but they only migrated from 32-bit 8.3 to 32-bit 8.4.  I assert
> that using isaexec in 8.4 is no worse than using explicit architecture
> setting in 8.4.
>
> Thoughts?

You assume that using 64 bit is always better than using 32 bit. This
is not the case. If you need more than 2 GB of RAM or have large
databases you are right. But if the database is not that big you are
better off using 32 bit. IMHO it is good to automatically make the
32/64 bit decision under the following circumstances:

(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 see that any of the above applies in the case of postgres.


Best regards

   -- Dago