Re: WAL, xl_heap_insert and tuple oid mystry

From: Greg Stark <gsstark(at)mit(dot)edu>
To: jagan <jaganrvce(at)yahoo(dot)com>
Cc: Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: WAL, xl_heap_insert and tuple oid mystry
Date: 2011-04-15 22:44:47
Message-ID: BANLkTikiVQ0RNWcMnrr7cqSkqRdsUUR4MA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Apr 15, 2011 at 6:29 PM, jagan <jaganrvce(at)yahoo(dot)com> wrote:
> Thanks for the pointer. I will try that route of recreating tuple
> descriptors and using heap_deform_tuple, although I suspect that "heap_deform_tuple"
> cannot be used by a stand-alone application (as it is not externally visible).
> So, I will have to basically rewrite parts of it.
> I am hoping to build something that is robust that makes use of as much
> of the existing unpacking code as possible. Any additional
> pointers you can give me would be much appreciated.
>

heap_deform_tuple isn't very complex itself, and doesn't have any
external dependencies aside from the macros in postgres.h. However it
*does* depend on having a tuple descriptor. This is the data structure
which says what columns to expect and what types they are. You
actually only need to know their sizes and whether they're variable
size, but that in the server that comes from their type.

The difficulty doing this from wal is that there's nowhere to get this
information. If you get it from the live database the structure may
not match the structure that was in place at the time the WAL was
written.

--
greg

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Smith 2011-04-16 05:48:23 Re: MMAP Buffers
Previous Message Kevin Grittner 2011-04-15 21:33:38 Re: Single client performance on trivial SELECTs