Re: [HACKERS] WAL, xl_heap_insert and tuple oid mystry

2011-04-15 Thread Alvaro Herrera
Excerpts from jagan's message of jue abr 14 17:30:17 -0300 2011: In general, what is the best way to unpack buffers containing tuples? I came across heap_form_tuple but not sure if that is most optimal way to go about. Is there some documentation on how tuples are internally stored? Unpack

Re: [HACKERS] WAL, xl_heap_insert and tuple oid mystry

2011-04-15 Thread jagan
Hi, In general, what is the best way to unpack buffers containing tuples? Unpack buffers containing tuples?  You don't do that.  If you have a page that comes from a table, you grab the tuple offset from the line pointer, and start decoding there (probably heap_deform_tuple is what you

Re: [HACKERS] WAL, xl_heap_insert and tuple oid mystry

2011-04-15 Thread Greg Stark
On Fri, Apr 15, 2011 at 6:29 PM, jagan jaganr...@yahoo.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).

Re: [HACKERS] WAL, xl_heap_insert and tuple oid mystry

2011-04-14 Thread jagan
Hi, Where is the OID of tuple stored in a WAL record of a tuple? If not with xl_heap_header, where is it stored? Is it stored at all? It's stored in the tuple data portion. I see it now. I was having alignment issues, which I resolved. Thanks for your help. I am still not sure if I

Re: [HACKERS] WAL, xl_heap_insert and tuple oid mystry

2011-04-12 Thread Heikki Linnakangas
On 11.04.2011 23:35, jagan wrote: Hi, Suppose I create a table as follows: CREATE TABLE test2 (name TEXT, age INTEGER) WITH oids; Now, for every tuple in this table is associated with a unique oid, which I can retrieve by: SELECT oid, name, age FROM test2; which works great. So far so good.

Re: [HACKERS] WAL, xl_heap_insert and tuple oid mystry

2011-04-12 Thread jagan
Hi, Where is the OID of tuple stored in a WAL record of a tuple? If not with xl_heap_header, where is it stored? Is it stored at all? It's stored in the tuple data portion. Is the OID also recorded with xl_heap_delete record as well or just the xl_heaptid? From my reading of the

Re: [HACKERS] WAL, xl_heap_insert and tuple oid mystry

2011-04-12 Thread Heikki Linnakangas
On 12.04.2011 19:42, jagan wrote: Where is the OID of tuple stored in a WAL record of a tuple? If not with xl_heap_header, where is it stored? Is it stored at all? It's stored in the tuple data portion. Is the OID also recorded with xl_heap_delete record as well or just the

Re: [HACKERS] WAL, xl_heap_insert and tuple oid mystry

2011-04-12 Thread Greg Stark
On Tue, Apr 12, 2011 at 7:55 AM, Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote: Maybe the WAL record you're looking at is a full-page image? A record with a full-page image includes a verbatim copy of the page, and the individual tuple is omitted in that case. It is? I thought

Re: [HACKERS] WAL, xl_heap_insert and tuple oid mystry

2011-04-12 Thread Tom Lane
Greg Stark gsst...@mit.edu writes: On Tue, Apr 12, 2011 at 7:55 AM, Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote: Maybe the WAL record you're looking at is a full-page image? A record with a full-page image includes a verbatim copy of the page, and the individual tuple is

Re: [HACKERS] WAL, xl_heap_insert and tuple oid mystry

2011-04-12 Thread Tom Lane
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes: On 12.04.2011 19:42, jagan wrote: In general, why is OID of a tuple relegated as just another tuple data, when it can replace xl_heaptid as a much more stable tuple identifier. Possibly. On the other hand, another common

Re: [HACKERS] WAL, xl_heap_insert and tuple oid mystry

2011-04-12 Thread Shigeru Hanada
(2011/04/13 8:34), Tom Lane wrote: Greg Starkgsst...@mit.edu writes: Doesn't pg_lesslog depend on this? One hopes not. AFAIK it's safe because pg_lesslog removes full-page image only when it has enough information for substitute incremental log. For example of XLOG_HEAP_INSERT, pg_lesslog