Re: reading row in backend - Mailing list pgsql-hackers

From Patrick Welche
Subject Re: reading row in backend
Date
Msg-id 20000516003702.F22468@quartz.newn.cam.ac.uk
Whole thread Raw
In response to Re: reading row in backend  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: reading row in backend  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Mon, May 15, 2000 at 07:22:30PM -0400, Tom Lane wrote:
> Patrick Welche <prlw1@newn.cam.ac.uk> writes:
> >> Um ... doesn't that line number in the COPY source data help any?
> 
> > Unfortunately not - in fact the 2nd large tuple allegedly has a smaller
> > line number than the first :(
> 
> Hmm, are you claiming that COPY is reporting a bogus line number?
> If so, that needs to be looked into.

Yup:

ERROR:  copy: line 57552, Tuple is too big: size 8152, max size 8140
PQendcopy: resetting connection
ERROR:  copy: line 26714, Tuple is too big: size 8164, max size 8140
PQendcopy: resetting connection

% wc /home/prlw1/db.out3631449 19833180 186847533 /home/prlw1/db.out

and the second line is in a table that is over half way through the file.

I'll take a look after some sleep..

> > Am I barking up the wrong tree if I think that the HeapTuple contains the
> > actual data? The first number in it would the primary key...
> 
> Type HeapTuple is a pointer to a HeapTupleData, which is just
> administrative overhead.  The t_data field of the HeapTupleData
> points at the actual tuple (a HeapTupleHeaderData followed by
> null-values bitmap and then the user data).  See include/access/htup.h

I think my question really is, is the user data meant to be just text? When
I tried printing a block, I just got jibberish - it could well be the way I
tried to print it, but I don't know what to expect..

Cheers,

Patrick


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: reading row in backend
Next
From: Philip Warner
Date:
Subject: Re: Proposal: replace no-overwrite with Berkeley DB