Heikki Linnakangas napsal(a):
Zdenek Kotala wrote:
The original proposal
(http://archives.postgresql.org/message-id/[EMAIL PROTECTED])
contains two parts. First part is implementation of --footprint cmd
line switch which shows you page layout structures footprint. It is
useful for development (mostly for in-place upgrade) and also for
manual data recovery when you need to know exact structures.
I'm afraid I still fail to see the usefulness of this. gdb knows how to
deal with structs,
If I correct that GDB knows structure only if you have debug version. But
usually you don't have debug version on production system. And another small
advantage is that --footprint switch is easy to use. It is easier that work with
gdb and you can easy get info from users who are not familiar with gdb.
and for manual data recovery you need so much more
than the page header structure.
Yeah, I know, but I didn't want to spend several days with full coding without
idea approval. There are special data, meta pages and so on which have to be added.
And if you're working at such a low
level, it's not that hard to calculate the offsets within the struct
manually.
I'm not sure if it is so easy. Are you able do it for SPARC, PPC or other non
x86 CPUs?
BTW, this makes me wonder if it would be possible to use the
upgrade-in-place machinery to convert a data directory from one
architecture to another? Just a thought..
Hmm, good question. For example ZFS is platform independent, you can take disk
from SPARC machine and plug it into x86 and ZFS works perfectly. ZFS converts
its own data during a read and any new block is written in a new format. You are
able read all binary platform independent data like MP3, JPEG and so on. But
PostgreSQL will not work, because PostgreSQL fails during pg_control file
reading, because endianes are different.
Convert data structures like PageHeader and so on could be possible but you
don't have control over user data types.
I think in this case is better to develop platform independent replication and
use this mechanism for data transfer.
However, there is still --footprint switch which is useful and it is
reason why I put it on wiki for review and feedback. The switch could
also use in build farm for collecting footprints from build farm members.
If we needed more information about the architectures, we could just
collect the output of pg_controldata. But I think the configure logs
already contains all the useful information.
It seems to be good idea. Only what we need is extend buildfarm to parse
config.log and shows this data for each build machine. It could also report
changes in alignment.
Zdenek
--
Zdenek Kotala Sun Microsystems
Prague, Czech Republic http://sun.com/postgresql
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
