Обсуждение: ¿¿¿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.
What else could be important there?
Thanks again....
--
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.
There's no problem in the memory allocation, just in relfrequency,
that's the "Big Problem" for me...
>This warning is shown when you write some extra bytes to the memory
>and size of your data goes beyond the allocated size.
There's no problem in the memory allocation, just in relfrequency,
that's the "Big Problem" for me...
>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...
What else could be important there?
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