Re: Persistence problem - Mailing list pgsql-general

From Tom Lane
Subject Re: Persistence problem
Date
Msg-id 18365.1273777738@sss.pgh.pa.us
Whole thread Raw
In response to Re: Persistence problem  ("I. B." <i.bre@live.com>)
Responses autovacuum: 50% iowait for hours  (Joao Ferreira <joao.miguel.c.ferreira@gmail.com>)
Re: Persistence problem  ("I. B." <i.bre@live.com>)
Re: Persistence problem  ("I. B." <i.bre@live.com>)
List pgsql-general
"I. B." <i.bre@live.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

pgsql-general by date:

Previous
From: S G
Date:
Subject: Re: SQL code runs slower as a stored function
Next
From: Tom Lane
Date:
Subject: Re: SQL code runs slower as a stored function