On Aug 1, 2009, at 8:24 AM, Alban Hertroys wrote:
> On 1 Aug 2009, at 24:53, Alexy Khrabrov wrote:
>> That's doable of course, but I wonder what would it take to get it
>> to work as-is, when building pg from source on each box, giving
>> their fairly similar characteristics. Or, if time_t is different,
>> would it be a show-stopper?
>
>
> Fairly similar? The one is a Linux kernel with a Linux environment,
> the other is a Mach kernel with a mostly BSD environment. I think
> you can expect all kinds of fun with line-ending styles (Mac
> traditionally used \r, Linux/Unix uses \n), locale handling
> differences, different time zone handling, different page sizes,
> different floating point sizes, etc.
>
> You're in for an interesting experiment, if you manage to get the DB
> running at all. If you do I'd thoroughly check for any data-
> misinterpretation. I suggest doing a diff on text-dumps from both
> databases and see if there are any differences. I'd still not trust
> the data in it afterwards, but whether that matters depends on what
> you intend to use it for.
>
> If you want safe and sound, use pg_dump/restore.
Well, my question, of course, is, how come all those differences might
affect PG binary data so much -- portable design would try to minimize
such effects, wouldn't it? Does it optimize for all of the above
intentionally, is it a side-effect of its design, and/or is there a
set of options for the build time which might minimize binary
incompatibility? I'd like to understand exactly why and how we get
binary incompatibility, and what exactly do we get for not having it,
and can it be a choice. There's a lot of databases out there. e.g.
Berkeley DB, where the backup is mv or ftp. Performance is allright,
too. I wish I could configure some of my PG ones that way...
Cheers,
Alexy