Re: reading row in backend

Поиск
Список
Период
Сортировка
От Patrick Welche
Тема Re: reading row in backend
Дата
Msg-id 20000516003702.F22468@quartz.newn.cam.ac.uk
обсуждение исходный текст
Ответ на Re: reading row in backend  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: reading row in backend  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: reading row in backend
Следующее
От: Philip Warner
Дата:
Сообщение: Re: Proposal: replace no-overwrite with Berkeley DB