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
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
