Thread: ¿¿¿past chunk end???

Hi We have been making some modifications to postgres catalog, but
it seems to be a problem with one of the fields we just added, exactly
in the time when inserting the right values to that specific field.

1. This is what It happens:

**************************************
template1=# CREATE TABLE test() AS VALID EVENT 2 WITH FREQUENCY '00:00:50.00' AS REAL TIME;
WARNING:  detected write past chunk end in CacheMemoryContext 0xb7212e0c
CREATE TABLE
**************************************

The creation it's possible, in fact, We have added 7 fields to Postgres
catalog (in pg_class) and there are no problems with the other fields values,
just with this one.


2. The field is defined this way:
// FILE: Parsenodes.h
// STRUCTURE: frequencyDefinition

typedef struct FrequencyDefinition
{
    NodeTag        type;
    bool        timeFrequency;
    FrequencyType    fttype;
    const char    *frequencyMeasure; // THIS ONE
} FrequencyDefinition;


3. The values are inserted this way:
// FILE: relcache.c
// FUNCTION: RelationBuildLocalRelation

**************************************
rel->rd_rel->relhasfrequency = freqDef->timeFrequency;  // Perfect Asignation

if((freqDef->fttype) == REAL_TIME)
            namestrcpy(&rel->rd_rel->relfrequencytype,(const char *)"REAL TIME");
        else
            namestrcpy(&rel->rd_rel->relfrequencytype,(const char *)"HISTORIC");

namestrcpy(&rel->rd_rel->relfrequency,freqDef->frequencyMeasure)
**************************************


We can see the other values whit a SELECT over PG_CLASS:

template1=# SELECT relname, relhasfrequency, relfrequencytype, relfrequency FROM pg_class WHERE relhasfrequency=true;

 relname  | relhasfrequency | relfrequencytype | relfrequency
 - - - - - -  + - - - - - - - - - - - - + - - - - - - - - - - - - - + - - - - - - - - -
 test         | t                        | REAL TIME          | 0
(1 row)

We have realized that in the assignation it takes just the first CHAR from '00:00:50.00',
and we tested the same assignation but just like this:

***************************************
namestrcpy(&rel->rd_rel->relfrequencytype,freqDef->frequencyMeasure);
//namestrcpy(&rel->rd_rel->relfrequency,freqDef->frequencyMeasure)
***************************************

And the result to the same query was:

template1=# SELECT relname, relhasfrequency, relfrequencytype, relfrequency FROM pg_class WHERE relhasfrequency=true;

 relname  | relhasfrequency | relfrequencytype | relfrequency
 - - - - - -  + - - - - - - - - - - - - + - - - - - - - - - - - - - + - - - - - - - - -
 test         | t                        | '00:00:50.00'         | 0
(1 row)


So please, anybody could tell me how to fix this?

Thanks...
--
Luis D. García M.
Telf: 0414-3482018

- FACYT - UC -
- Computación -

Carefully check all the palloc's you are doing in your code.
This warning is shown when you write some extra bytes to the memory
and size of your data goes beyond the allocated size.

--Imad
EnterpriseDB (www.enterprisedb.com)


On 11/1/06, luis garcia <ldgarc@gmail.com> wrote:
>
> Hi We have been making some modifications to postgres catalog, but
> it seems to be a problem with one of the fields we just added, exactly
> in the time when inserting the right values to that specific field.
>
> 1. This is what It happens:
>
> **************************************
> template1=# CREATE TABLE test() AS VALID EVENT 2 WITH FREQUENCY
> '00:00:50.00' AS REAL TIME;
> WARNING:  detected write past chunk end in CacheMemoryContext 0xb7212e0c
> CREATE TABLE
> **************************************
>
> The creation it's possible, in fact, We have added 7 fields to Postgres
> catalog (in pg_class) and there are no problems with the other fields
> values,
>  just with this one.
>
>
> 2. The field is defined this way:
>  // FILE: Parsenodes.h
>  // STRUCTURE: frequencyDefinition
>
>  typedef struct FrequencyDefinition
>  {
>      NodeTag        type;
>      bool        timeFrequency;
>      FrequencyType    fttype;
>      const char    *frequencyMeasure; // THIS ONE
>  } FrequencyDefinition;
>
>
> 3. The values are inserted this way:
> // FILE: relcache.c
> // FUNCTION: RelationBuildLocalRelation
>
> **************************************
> rel->rd_rel->relhasfrequency = freqDef->timeFrequency;  // Perfect
> Asignation
>
> if((freqDef->fttype) == REAL_TIME)
>
> namestrcpy(&rel->rd_rel->relfrequencytype,(const char
> *)"REAL TIME");
>         else
>
> namestrcpy(&rel->rd_rel->relfrequencytype,(const char
> *)"HISTORIC");
>
> namestrcpy(&rel->rd_rel->relfrequency,freqDef->frequencyMeasure)
> **************************************
>
>
> We can see the other values whit a SELECT over PG_CLASS:
>
> template1=# SELECT relname, relhasfrequency, relfrequencytype, relfrequency
> FROM pg_class WHERE relhasfrequency=true;
>
>  relname  | relhasfrequency | relfrequencytype | relfrequency
>  - - - - - -  + - - - - - - - - - - - - + - - - - - - - - - - - - - + - - -
> - - - - - -
>  test         | t                        | REAL TIME          | 0
> (1 row)
>
> We have realized that in the assignation it takes just the first CHAR from
> '00:00:50.00',
> and we tested the same assignation but just like this:
>
> ***************************************
> namestrcpy(&rel->rd_rel->relfrequencytype,freqDef->frequencyMeasure);
> //namestrcpy(&rel->rd_rel->relfrequency,freqDef->frequencyMeasure)
> ***************************************
>
> And the result to the same query was:
>
> template1=# SELECT relname, relhasfrequency, relfrequencytype, relfrequency
> FROM pg_class WHERE relhasfrequency=true;
>
>   relname  | relhasfrequency | relfrequencytype | relfrequency
>   - - - - - -  + - - - - - - - - - - - - + - - - - - - - - - - - - - + - - -
> - - - - - -
>   test         | t                        | '00:00:50.00'         | 0
>  (1 row)
>
>
> So please, anybody could tell me how to fix this?
>
> Thanks...
> --
> Luis D. García M.
> Telf: 0414-3482018
>
> - FACYT - UC -
> - Computación -

On Wed, Nov 01, 2006 at 08:49:48AM -0400, luis garcia wrote:
> Hi We have been making some modifications to postgres catalog, but
> it seems to be a problem with one of the fields we just added, exactly
> in the time when inserting the right values to that specific field.

Well, it's a bit hard to tell since you don't tell what changes you
actually made to the catalog. Did you remember to update the length to
the catalog entry and update the struct and all those details?

In particular:
> template1=# SELECT relname, relhasfrequency, relfrequencytype, relfrequency
> FROM pg_class WHERE relhasfrequency=true;
>
> relname  | relhasfrequency | relfrequencytype | relfrequency
> - - - - - -  + - - - - - - - - - - - - + - - - - - - - - - - - - - + - - -
> - - - - - -
> test         | t                        | REAL TIME          | 0
> (1 row)

What's the type of "relfrequency" actually?

Much more info needed...

Have a nice day,
--
Martijn van Oosterhout   <kleptog@svana.org>   http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.

Hi, thanks for your answers...


>Well, it's a bit hard to tell since you don't tell what changes you
>actually made to the catalog. Did you remember to update the length to
>the catalog entry and update the struct and all those details?

Well about the changes I have made, they are working just fine. All the
structures length have been updated and as I said we added 7 new fields
to pg_class structure and there was no problem. The problem here is with
relfrequency only.

> What's the type of "relfrequency" actually?>

I'm sorry, but I forgot to show you the relfrequency definition in pg_class.

Here It is:

**************************************************************************************************
// FILE: pg_class.h
// STRUCTURE: CATALOG(pg_class,1259) BKI_BOOTSTRAP
.
.
.
bool        relvalidtime;    /* T if the table has a valid time attribute */
NameData    relvttype;    /* The type of the valid time column of the table:
                                       * event, state or null (when the table isn't a TSQL2
                                       * temporal table)
                                       */

int2        relvtprecision;    /* The precision of the valid time column. By default 0 */
bool        reltranstime;    /* T if the table has TSQL2 transaction time attribute */
bool        relhasfrequency;/* relation has time frequency */
NameData    relfrequencytype;/* table time frequency type (REAL TIME, HISTORIC)*/
NameData    relfrequency;    /* table time frequency value*/
.
.
.
**************************************************************************************************
These are the seven fields we just added, and as I said the only one with
problems is relfrequency.

> Much more info needed...

Thanks again....

--
Luis D. García M.
Telf: 0414-3482018

- FACYT - UC -
- Computación -

"luis garcia" <ldgarc@gmail.com> writes:
> Well about the changes I have made, they are working just fine. All the
> structures length have been updated and as I said we added 7 new fields
> to pg_class structure and there was no problem. The problem here is with
> relfrequency only.

pg_class is notoriously tricky to add fields to --- there are more
undocumented dependencies than you might think.  If you check the
archives, there was a thread only a week or so back with someone who
was one or two edits short of getting such a change to work.

But what I'm wondering in your case is whether your code thinks it can
set relfrequency and/or the preceding field relfrequencytype to null.
You can't use a C struct to address any fields beyond the first
possibly-nullable field, because the constant offsets computed by the
compiler won't work.  Also, initdb makes some assumptions derived from
this fact to decide which system-catalog columns to mark NOT NULL.
If "\d pg_class" shows not-null column markings that are at variance
with what you intend, you have a problem.

            regards, tom lane