Re: Page layout footprint

From: Zdenek Kotala <Zdenek(dot)Kotala(at)Sun(dot)COM>
To: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Page layout footprint
Date: 2008-09-05 09:01:20
Message-ID: 48C0F560.2030808@sun.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Heikki Linnakangas napsal(a):
> Zdenek Kotala wrote:
>> The original proposal
>> (http://archives.postgresql.org/message-id/489FC8E1.9090307@sun.com)
>> 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Zdenek Kotala 2008-09-05 09:20:00 Re: Prototype: In-place upgrade
Previous Message Heikki Linnakangas 2008-09-05 08:47:28 Re: New FSM patch