Re: Persistence problem

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "I(dot) B(dot)" <i(dot)bre(at)live(dot)com>
Cc: kleptog(at)svana(dot)org, dalroi(at)solfertje(dot)student(dot)utwente(dot)nl, pgsql-general(at)postgresql(dot)org
Subject: Re: Persistence problem
Date: 2010-05-13 19:08:58
Message-ID: 18365.1273777738@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

"I. B." <i(dot)bre(at)live(dot)com> writes:
> When I do this:
> realResult = (mPoint *)palloc(result->length);
> memcpy(realResult, result, result->length);
> I get a right result in the same session, but corrupted in the next
> one.

I'm guessing a bit here, but I think what is happening is this:

> typedef struct {
> int4 length;
> int noOfUnits;
> void *units; // this is later casted to uPoint *
> } mapping_t;

You're storing the above-named struct on disk, right? And the "units"
pointer is pointing to an array that's somewhere else in memory? As
long as the somewhere-else array survives, it will seem like everything
is okay. But in a new session, that data in memory will certainly not
be there anymore.

You can't use pointers in data structures that are to be stored on disk.
The array data needs to be "in line" in the data structure, and
accounted for in the length word.

Martin's advice about using VARSIZE/VARDATA is good too. Depending on
which PG version you're using, you might be able to get along without
that so long as you haven't marked the data type toastable (by using
a non-PLAIN storage option in CREATE TYPE). But unless that array is
always pretty darn small, you're going to want to allow this type to
be toasted.

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2010-05-13 19:19:31 Re: SQL code runs slower as a stored function
Previous Message Yeb Havinga 2010-05-13 19:06:53 Re: List traffic