ERROR: index row size
Hello,
I'm having a big trouble with the index size! I have looked for a solution
in the internet, but the solutions that I found don't fit for me!
I developed a new data type using C and add this new type on PostgreSQL.
Basically, the data type is: (DateADT, DateADT) with some temporal rules
that I'm researching! The data type is ok; the in, out, receive and send
functions are ok; some operations are ok. But the index operators and
functions are not working properly! Actually I can use them, but in some
cases an error occurs about index row size.
I'm sure that the functions in, out, receive and send are well
implemented. I think the problem is that the data type is really big and
needs a "big index".
The implementation code of the data type is::
typedef struct t_periodo
{
DateADT tvi;
DateADT tvf;
} Periodo;
Any ideas to solve my problem? Perhaps increasing the BLOCKSIZE could be
one solution. Not very smart one, but can solve temporally my problem?!?!
Thanks in advance!
"Rodrigo Sakai" <rodrigo.sakai@poli.usp.br> writes:
I developed a new data type using C and add this new type on PostgreSQL.
Basically, the data type is: (DateADT, DateADT) with some temporal rules
that I'm researching! The data type is ok; the in, out, receive and send
functions are ok; some operations are ok. But the index operators and
functions are not working properly! Actually I can use them, but in some
cases an error occurs about index row size.
You have a bug in your datatype code. There's no way an 8-byte datatype
should produce that error.
regards, tom lane
Rodrigo Sakai wrote:
Hello,
I�m having a big trouble with the index size! I have looked for a
solution in the internet, but the solutions that I found don�t fit for me!
I would guess you have an allocation calculation error/memory leak
somewhere in your implementation - maybe post a link to the actual C
code (in case someone wants to have a look at it for you)!
(Valgrind might help you here, otherwise you can set a few breakpoints
in gdb and check what is going on).
Cheers
Mark