Re: Page layout footprint - Mailing list pgsql-hackers

From Zdenek Kotala
Subject Re: Page layout footprint
Date
Msg-id 48C0F560.2030808@sun.com
Whole thread Raw
In response to Re: Page layout footprint  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Responses Re: Page layout footprint
Re: Page layout footprint
List 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



pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: New FSM patch
Next
From: Zdenek Kotala
Date:
Subject: Re: Prototype: In-place upgrade